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EXECUTIVE  SUMMARY 


The  afloat  installation  approval  process  is  a  very  stringent  and  rigorous  set  of 
NAVSEA  processes  and  policies.  In  the  summer  of  2003,  an  ashore  C4I  system,  the 
Ocean  Surveillance  Information  System  (OSIS)  Evolutionary  Development  (OED),  was 
installed  on  board  the  USS  Blue  Ridge  (LCC-19).  This  was  the  first  complete  installation 
of  OED  on  board  a  ship  and  the  first  time  the  OED  team  addressed  the  requirements  of  an 
afloat  installation.  Therefore,  the  OED  installation  aboard  LCC-19  provided  a  unique 
case  study  of  the  afloat  installation  development  and  approval  process. 

This  thesis  documents  the  installation  of  OED  on  board  the  USS  Blue  Ridge 
including  the  background  behind  the  installation,  the  challenges  and  issues  faced  by  the 
installation  team,  how  those  challenges  and  issues  were  overcome,  and  lessons  learned 
for  future  installations.  This  thesis  provides  future  installers  with  recommendations  to 
plan  and  complete  future  afloat  installations  better. 
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I.  INTRODUCTION 


A.  BACKGROUND 

Command  and  Control  (C2)  is  a  critical  piece  of  any  mission  conducted  by  our 
Warfighters.  One  very  important  aspect  of  C2  is  intelligence  (I)  (Edwards,  1990). 
Intelligence  allows  the  Warfighter  to  assess  the  battlefield,  courses  of  action,  and 
probable  outcomes.  One  of  the  tools  the  Warfighter  uses  to  help  him  carry  out  C2I 
situational  awareness  is  the  Ocean  Surveillance  Information  System  (OSIS)  Evolutionary 
Development  (OED)  (COMSECONDFLT,  2201 15Z  NOV  03).  Please  note  version  5.0 
of  OED  will  be  the  first  version  of  the  OED  follow-on  system,  Joint  Cross  Domain 
Exchange  (JCDX.  JCDX  employs  web  services  to  provide  C2I  services  to  United  States 
and  coalition  partners  across  a  wide  array  of  security  domains.  OED  is  a  suite  of 
applications,  graphical  tools,  and  data  that  allows  the  Warfighters  from  different  Services 
and  other  countries  to  work  together  to  perfonn  C2I  functions.  OED  is  built  upon  a 
common  foundation  of  services  and  functions  called  the  Common  Operating 
Environment  (COE).  The  COE  was  developed  to  promote  interoperability  and  reuse  of 
common  components  of  any  C2I  system  (Rodriguez,  2004). 

Today’s  Global  War  on  Terror  (GWOT)  is  a  Coalition  war 
(COMSECONDFLT/COMTHIRDFLT,  211942Z  FEB  03).  The  question  facing  our 
Warfighters  is,  “How  do  we  share  our  C2I  products  with  our  allies  and  still  protect  the 
security  and  sensitivity  of  that  data?”  Back  in  the  mid- 1 990 ’s,  a  project  was  started  to 
answer  that  question  on  a  COE-based  system.  That  project  was  OED  and  the  engineering 
approach  utilized  to  provide  security  was  Multi-Level  Security  (MLS). 

MLS  technology  allows  the  Warfighter  to  address  the  numerous  security  domains 
inherent  in  today’s  military  environment.  These  domains  range  from  the  common 
security  enclaves  of  TOP  SECRET,  SECRET,  CONFIDENTIAL,  and  UNCLASSIFIED 
to  the  more  cumbersome  domains  of  Specialized  Compartmented  Infonnation  (SCI), 
Special  Category  (SPECAT),  Special  Access  Programs  (SAP),  and  those  are  just  US 
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security  domains.  Coalition  networks  and  communication  lines  are  now  a  necessary 
piece  of  this  security  puzzle. 

Although  the  ability  to  securely  and  safely  share  C2I  information  is  the  driving 
force  behind  an  MLS-capable  C2I  system,  there  are  other  benefits.  It  is  not  uncommon 
for  the  Warfighter  to  have  numerous  monitors  on  his  desk  in  order  to  assess  the  data 
found  in  each  of  these  domains.  However,  this  approach  is  flawed  due  to  the  size, 
weight,  and  power  (SWAP)  limitations  found  aboard  a  ship  and  due  to  the  inefficiencies 
and  inaccuracies  involved  in  the  Warfighter  conducting  correlation  of  data  in  his  head 
vice  using  correlation  algorithms  to  perform  that  very  tedious  and  convoluted  task.  MLS 
technology  addresses  these  issues  by  tagging  all  the  data  with  their  corresponding 
security  labels.  Thus,  all  the  data  can  now  reside  in  one  database  so  the  correlation 
algorithms  can  process  the  data  thoroughly  and  the  Warfighter  can  see  all  the  data  that  he 
is  authorized  to  see  based  on  his  clearances,  need-to-know,  and  physical  location.  MLS 
is  an  incredible  means  to  utilize  the  entire  set  of  data,  thus  providing  value-added  to  all 
the  participants  in  the  database,  and  still  ensure  the  data  is  protected  so  no  one  can  see 
data  that  they  are  not  authorized  to  access  (Miller,  2003). 

Due  to  the  nature  of  naval  warfare,  systems  on  board  ships  must  meet  stringent 
requirements  and  the  installation  of  afloat  systems  must  follow  established  processes. 
These  processes  provide  step-by-step  guidance  in  some  aspects  and  broad  areas  left  to 
interpretation  in  other  areas.  These  processes  are  often  circumvented  or  performed 
piecemeal  based  on  each  specific  installation.  It  is  very  rare  the  entire  process  is 
followed  in  an  installation.  Since  OED  is  an  ashore  system,  the  first  afloat  installation  of 
OED  on  board  the  USS  Blue  Ridge  (LCC-19)  provided  a  unique  opportunity  to  gather 
lessons  learned  and  apply  them  to  best  practices.  This  thesis  will  greatly  benefit  future 
installations. 

B.  PURPOSE 

The  purpose  of  this  thesis  is  to  document  the  lessons  learned  from  the  installation 
of  the  OED  on  board  the  USS  Blue  Ridge.  OED  is  an  ashore  MLS  C2I  computer  system 
that  is  fielded  at  the  Joint  Intelligence  Centers  and  Joint  Analysis  Centers.  The  MLS 
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aspect  of  OED  allows  the  operator  to  view  and  add  value  to  data  from  multiple  security 
domains  on  one  workstation.  Since  the  on  board  environment  of  a  ship  is  very 
constrained  by  SWAP  considerations,  this  technology  is  very  advantageous.  As  with  any 
afloat  installation,  there  were  problems  and  issues  to  work  out  in  order  to  complete  the 
installation.  However,  the  OED  installation  aboard  LCC-19  provided  a  unique  case  study 
of  the  afloat  installation  process  because  the  USS  Blue  Ridge  installation  was  the  first 
complete  afloat  installation  for  OED.  This  thesis  documents  these  challenges  and  issues, 
how  they  were  overcome  and  provides  future  installers  recommendations  to  improve  the 
planning  of  future  afloat  installations. 

C.  RESEARCH  QUESTIONS 

The  following  research  questions  are  addressed: 

1 .  What  is  OED  and  why  should  it  be  installed  afloat? 

2.  What  is  the  installation  process  and  what  are  the  various  documents, 
diagrams,  lists,  plans,  etc.  required  for  a  robust  shipboard  system  design 
and  installation? 

3.  What  are  the  approval/authorization/certifications  required  for  an  afloat 
installation? 

4.  Which  organizations  are  involved  in  the  installation  process  and  what 
roles  do  they  play? 

5.  What  are  the  risks  and  challenges  associated  with  an  afloat  installation? 

6.  What  lessons  were  learned  from  this  afloat  installation  that  can  benefit 
future  installations? 

D.  BENEFIT  OF  THE  STUDY 

This  study  develops  lessons  learned  and  identifies  best  practices  for  afloat 
installations.  Although  every  afloat  installation  is  unique,  the  installation  policies  and 
procedures  attempt  to  provide  the  installer  with  a  common  baseline  for  every  installation. 
The  lessons  learned  and  best  practices  discovered  in  this  installation  and  documented  in 
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this  thesis  will  strengthen  the  foundation  policies  and  processes  and  help  installers  work 
through  unique  issues  that  will  inevitably  arise. 

E.  SCOPE 

This  thesis  explores  the  installation  of  OED  on  board  the  USS  Blue  Ridge  to 
include  an  analysis  of  the  installation  process;  the  products  of  this  process;  and  the 
lessons  learned  during  the  installation. 

F.  METHODOLOGY 

1 .  Fully  document  the  genesis  of  the  OED  afloat  requirement. 

2.  Conduct  a  thorough  review  of  the  installation  process,  the  parties 
involved,  and  the  requirements  mandated  by  the  process. 

3.  Interview  the  parties  involved  in  the  OED  installation. 

4.  Review  the  documents,  diagrams,  charts,  etc.  utilized  in  the  OED 
installation  on  board  LCC-19. 

5.  Review  the  issues  and  obstacles  encountered  during  the  installation. 

6.  Identify  lessons  learned  and  best  practices  for  all  future  installations  based 
on  the  lessons  learned  from  the  OED  installation  aboard  LCC-19. 

G.  ORGANIZATION  OF  THE  STUDY 

This  thesis  is  organized  in  a  fashion  to  familiarize  the  reader  with  the  whole 
installation  process.  The  process  starts  with  a  Warfighter  requirement  and  an  analysis  of 
possible  solutions  to  answer  this  requirement  in  Chapter  II.  Once  the  engineering 
solution  has  been  identified,  the  solution  has  to  be  implemented  or,  in  this  case,  installed 
on  board  a  ship.  The  installation  of  a  system  on  board  a  ship  requires  stringent  processes 
and  procedures  to  ensure  the  initial  requirement  is  met  without  diminishing  the  existing 
infrastructure,  applications,  systems,  security  boundaries,  etc.  The  installation  process 
and  how  it  applies  to  a  new  afloat  installation  is  the  subject  of  Chapters  III  and  IV. 
Because  of  the  uniqueness  of  the  OED  installation  afloat,  the  lessons  learned  from  this 
installation  are  very  valuable  and  Chapter  V  identifies  those  lessons  learned  and  how  to 
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apply  them  to  future  installations.  Chapter  VI  provides  a  conclusion  with 
recommendations  for  further  study. 
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II.  OED  AND  INSTALLATION  PROCESS  REVIEWS 


A.  OCEAN  SURVEILLANCE  INFORMATION  SYSTEM  (OSIS) 

EVOLUTIONARY  DEVELOPMENT  (OED) 

In  order  to  better  understand  OED  and  the  unique  capabilities  it  provides  the 
Warfighter,  it  is  important  to  explore  the  critical  aspects  of  OED.  These  aspects  include 
the  history  of  OED,  key  definitions  regarding  the  security  aspects  of  the  OED  system,  the 
requirements  that  drove  the  acquisition  process  to  install  OED  afloat,  and  a  quick  look  at 
the  alternatives  available  to  answer  those  requirements. 

1.  History  and  System  Overview 

The  problem  of  timely  access  to  information  at  multiple  security  levels  has 
challenged  the  computer  security  research  and  engineering  community  for  several 
decades  (Brenneman  et  al,  1997).  Early  efforts  were  focused  on  the  development  of  high 
assurance  security  kernels  by  vendors.  The  resulting  systems  pennitted  controlled  sharing 
of  sensitive  infonnation  by  users  at  multiple  security  levels.  These  systems  often  used 
reference  validation  mechanisms  with  primitive  interfaces  that  did  not  meet  the  users’ 
desire  for  a  highly  responsive  rich  system  interface. 

The  early  1980’s  ushered  in  the  creation  of  complex  applications  and  the  notion 
of  multi-level  systems.  Challenges  included  allowing  users  to  view  multiple  security 
levels  simultaneously,  while  minimizing,  if  not  completely  avoiding,  modifications  to 
underlying  security  kernels  used  to  enforce  mandatory  security  policies.  It  was 
demonstrated  that  complex  functionality  could  be  provided  outside  of  the  reference 
validation  mechanism.  In  most  cases  these  architectures  were  custom-built  “one  of’ 
systems.  This  precluded  the  rapid  development  and  fielding  of  such  solutions. 

However,  the  rapid  growth  and  pervasiveness  of  the  personal  computers  (PCs) 
and  workstations  and  the  proliferation  of  productivity  tools  in  tandem  has  allowed  new 
solutions  to  be  introduced  easily  and  cheaply.  The  use  of  information  technology  (IT)  is 
no  longer  a  luxury  used  by  science  and  academia,  but  the  premier  tool  for  DoD  and 
industry.  DoD  is  making  enormous  investments  in  Commercial  off-the-shelf  (COTS)  and 
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commodity  PC  products.  This  shift  to  COTS  has  lead  to  new  requirements:  the  ability  to 
incorporate  patches  and  updates  to  existing  COTS  products  and  the  ability  to  enlarge  the 
desktop-based  software  suite  as  new  products  become  available  ( NAVSEA  Instruction 
9083.1 -COMMERCIAL  OFF  THE  SHELF  (COTS)  POLICY,  2002)..  Unfortunately, 
multi-level  security  solutions  did  not  evolve  at  the  same  rate  as  personal  computing.  The 
problem  for  DoD  systems  includes  not  only  the  provision  of  access  control  and 
movement  of  data  based  on  fixed  sensitivity  levels,  but  the  preservation  of  compatibility 
with  COTS,  Government  off-the-shelf  (GOTS),  and  coalition  application  software.  When 
protecting  sensitive  information  is  paramount,  then  the  solution  set  is  comprised  of  high- 
cost  applications.  In  contrast,  when  compatibility  with  COTS/GOTS  takes  precedence, 
then  instead  of  employing  high  cost  trusted  systems  for  timely  information  sharing;  each 
access  class  is  relegated  to  a  separate  infonnation  system  or  enclave.  These  independent 
“system  high”  enclaves  are  established  by  “air-gapping”  the  respective  networks;  using 
automated  guards;  or  using  replication  schemes  to  achieve  isolation. 

The  tragic  events  of  September  11,  2001,  highlighted  the  need  for  the  rapid 
sharing  of  disparate  sensitive  infonnation.  The  DoD  is  now  faced  with  the  challenge  of 
getting  mission-critical  and  time- sensitive  infonnation  into  the  hands  of  people,  DoD  or 
non-DoD,  which  need  it  in  a  short  period  of  time  so  it  may  be  used  effectively. 
Historically  the  infonnation  resided  in  information  systems  that  did  not  provide  access  to 
persons  outside  the  immediate  community  of  interest  (i.e.  releasable  FBI)  and  that 
information  was  carefully  protected  and  guarded  (9/1 1  Commission,  2004). 

The  DoD  relies  on  information  systems  to  support  the  missions  of  nearly  every 
component  organization.  In  most  cases  today,  information  is  protected  at  the  highest 
classification  level  of  the  data  in  the  system,  the  system-high  level.  Unfortunately,  the 
information  is  not  readily  accessible  by  persons  not  cleared  to  the  system-high  level,  even 
though  the  information  being  sought  may  be  of  a  lower  classification  level  and  thereby 
releasable  to  the  requester. 

Operating  information  systems  in  this  manner  often  results  in  the  over¬ 
classification  of  data,  over-clearing  of  personnel,  and  system  redundancies  and 
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inefficiencies.  This  situation  commonly  exists  throughout  the  DoD.  What  is  needed  is  a 
means  by  which  the  actual  security  level  of  the  information  can  be  maintained  and 
information  can  be  appropriately  protected,  automatically  processed,  and  efficiently 
distributed.  Users  also  need  timely  access  to  the  data  and  the  various  processing  and 
communications  resources  that  they  require  to  accomplish  their  jobs  (Myer  &  Patterson, 
2003). 

In  addition,  staff  members  need  to  access  and  fuse  data  and  other  resources  that 
are  available  on  several  disparate  systems  to  perform  their  duties.  Each  system  usually 
has  its  own  interface  (e.g.,  via  a  specific  set  of  tenninals  or  workstations),  thus  requiring 
multiple  terminals  that  take  valuable  space  in  command  centers,  offices,  and  computer 
rooms.  The  maintenance  of  these  redundant  databases  is  another  unfavorable  condition 
that  results  from  using  separate  systems  for  each  security  level.  Often  a  separate  database 
must  be  created  and  maintained  for  each  security  level  processed.  The  use  of  these 
multiple  databases  presents  several  operational  problems.  First,  it  fragments  infonnation. 
A  collection  of  information  regarding  a  specific  event  may  be  split  across  multiple 
systems  of  different  security  levels.  Incomplete  or  misleading  infonnation  may  result 
unless  pertinent  data  can  be  obtained  from  all  related  systems.  Second,  infonnation  of  a 
lower  classification  may  be  unnecessarily  upgraded  in  the  higher-level  systems,  resulting 
in  its  over-classification  and  consequent  limited  access.  As  a  result,  duplication  and 
multiple  classifications  of  the  same  infonnation  occur.  Third,  the  maintenance  of  multiple 
databases  is  staff  and  system  administrator  intensive  and  depletes  valuable  system 
resources.  Because  the  data  may  change  continually,  updating  data  bases  often  results  in 
inconsistent  views  of  the  cunent  information  across  different  levels.  The  constantly 
changing  nature  of  the  data,  combined  with  human  updating,  often  results  in  outdated 

information  at  one  or  more  of  the  security  levels. 

One  of  the  greatest  drawbacks  of  having  multiple  systems  operating  at  different 
security  levels  is  the  inability  to  share  the  computer  and  communication  system 
infrastructures,  such  as  cabling,  network  components,  printers,  workstations,  and  hosts.  If 
sharing  these  resources  were  possible,  equipment,  operations,  and  maintenance  costs 
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would  decrease,  and  significant  gains  in  overall  system  reliability  could  be  increased 
(Miller,  2003). 

2.  Afloat  Derived  Requirements 

As  evidenced  in  Operation  Enduring  Freedom  and  Operation  Iraqi  Freedom,  the 
US  Warfighter  is  a  member  of  a  strong  team  of  coalition  partners  all  sharing  the  common 
goal  of  defeating  terrorism  and  oppression.  One  critical  aspect  of  winning  this  fight  is  the 
ability  to  share  information  across  security  domains  while  ensuring  sensitive  information 
is  kept  secure.  This  capability  is  termed  Cross  Domain  Solutions  (CDS) 
(COMSECONDFLT,  2201 15Z  NOV  03).  One  end  of  the  spectrum  of  CDS  is  to  put  all 
information  in  one  domain  so  everyone  has  access  to  all  the  information  at  all  times. 
This  end  of  the  spectrum  ensures  speedy  access  to  critical  information  but  it  also 
eliminates  protection  for  sensitive  information  such  as  source  of  information  (i.e.,  sensor, 
human  collection),  precision  of  information  (i.e.,  sensitivity  of  sensors),  timeliness  of 
delivery  of  information,  bilateral  agreements  between  allies  (i.e.,  in  order  for  Country  A 
to  use  Country  B’s  information,  Country  A  agrees  not  to  share  Country  B’s  information 
with  Country  C),  and  many  other  security/sensitivity  issues.  The  other  end  of  the  CDS 
spectrum  is  to  over-classify  the  data  so  one  can  ensure  the  sensitivity  of  the  data  but,  in 
the  process,  eliminate  the  usefulness  of  the  data  by  severely  limiting  access  to  the  data. 

A  middle  ground  must  be  utilized  to  provide  the  Warfighter  with  the  positives  of 
both  extremes  while  minimizing  the  risks  of  both  extremes.  This  middle  ground  has 
resulted  in  the  security  domains  present  in  today’s  DoD  and  coalition  operations.  The 
utilization  of  security  domains  presents  three  scenarios  for  information  security/sharing: 
system-high,  multiple  single  levels  (MSL),  and  MLS  (Myer  &  Patterson,  2003). 

System-high:  System-high  systems  do  not  address  the  security  of  individual 
pieces  of  data.  In  this  scenario,  all  data  is  considered  to  be  at  the  security  level  of  the 
system.  Therefore,  the  data  is  easily  accessible  to  any  user  authorized  at  that  security 
level  but  data  can  also  be  easily  over-classified.  For  example,  a  piece  of  data  classified  as 
CONFIDENTIAL  introduced  into  a  SECRET  system-high  system  will  automatically 
become  SECRET  data.  System-high  systems  also  provide  very  limited  bilateral 
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agreement  compliance,  thus  again  limiting  the  ability  to  share  data  with  other  coalition 
members. 


MSL:  MSL  is  a  type  of  security  comprised  of  relatively  untrustworthy  single 
level  systems.  Separation  of  data  and  trust  is  placed  in  controlled  interfaces  between  the 
less  trustworthy  components.  These  controlled  interfaces  (e.g.,  guards  and  sanitizers)  are 
typically  smaller  automated  information  systems  running  a  dedicated  program,  providing 
a  dedicated  function.  MSL  implementations  maintain  multiple  instantiations  of  servers, 
clients,  applications,  and  databases  to  serve  each  security  enclave  and  pass  the  data  up  or 
down  using  guarding  and  sanitization  tools.  Because  of  this,  it  is  not  uncommon  to  find 
three  or  more  workstations  in  a  single  workspace  aboard  our  ships  (Myer  &  Patterson, 
2003). 


MLS:  There  are  different  aspects  of  MLS  that  must  be  addressed  to  fully 
understand  MLS  capabilities.  There  is  external  MLS  -  the  ability  to  take  information  / 
intelligence  from  multiple,  trusted,  security  levels  and  disseminate  derived  products  out 
to  multiple,  trusted,  security  levels.  There  is  internal  MLS  -  the  ability  to  restrict  access 
to  data  on  a  network  depending  on  the  security  level  of  the  user.  There  is  also  MLS 
communications  -  systems  that  can  take  message  traffic  from  multiple  communications 
paths  and  transmit  messages  out  via  multiple  communications  paths. 


The  afloat  requirement  presented  to  the  acquisition  community  by  the  USS  Blue 


Ridge  and  the  Commander,  Carrier  Group  Seven  (CCG  7)  staff  embarked  on  board  was 
directly  derived  from  CCG  7  post-deployment  lessons  learned  analysis  following 
operations  in  support  of  Operation  Enduring  Freedom.  This  requirement  was  further 


delineated  in  a  series  of  reference  messages  identified  in  Table  1. 


FLEET  GEN1 

ERATED  REQUIREMENTS 

MSGID 

FROM 

SUBJECT 

021132Z  JAN  04 

COMENTSTRKGRU 

OED  MID-CRUISE  REPORT 

-  ABILITY  TO  RECEIVE,  QUEUE,  AND  FORWARD  RECORD  MESSAGE  TRAFFIC  FROM 


UNCLASSIFIED  THROUGH  SCI  COMPARTMENTS 

o  HAS  IMPROVED  WATCHSTANDERSAND  LEADERSHIP'S  ABILITY  TO  REVIEW  TRAFFIC 
IN  ONE  PLACE  WITHOUT  HAVING  TO  ACCESS  MULTIPLE  SYSTEMS  AND  INDIVIDUAL 
QUEUES  LEADING  TO  TIME  SAVINGS  AND  INCREASED  EFFICIENCY 

-  MLS  FUNCTIONALITIES  FOR  MESSAGE  PROCESSING/HANDLING,  LONG  TERM  TRACK  DATA 
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_ FLEET  GENERATED  REQUIREMENTS _ 

ANALYSIS,  ACCESS  TO  SCI  INTELINK  AND  PRE-LOADED  NATIONAL  DATABASES,  AND  SCI 
CHAT 

-  ABILITY  TO  WORK  WITH  BOTH  GENSER  AND  SCI  MATERIAL  ON  ONE  WORKSTATION 


MSGID 

FROM 

SUBJECT 

220115Z  NOV  03 

COMSECONDFLT 

SUBJ/OSIS  EVOLUTIONARY  DEVELOPMENT  (OED) 
UPDATE  (SERIAL  3):  OED  /FLEET  INTELLIGENCE 
REQUIREMENTS 

-  OED  PROVIDES  AN  MLS  ENVIRONMENT  WHOSE  FOUNDATION  OFFERS  A  REALIZABLE 

OPPORTUNITY  FOR  A  CROSS  DOMAIN  SOLUTION  (CDS)  THAT  SPANS  THE  COLLATERAL  AND 
SCI  ENVIRONMENTS. 

-  INTELLIGENCE  PRODUCTION  AT  THE  SCI  LEVEL,  AND  AUTOMATIC,  RAPID,  RELIABLE 
DISSEMINATION  INTO  THE  COLLATERAL  ENVIRONMENT  OF  THE  WARFIGHTER 

-  WATCHST ANDERS  SEARCH  ARCHIVED  MESSAGES  FOR  THEMATIC  ISSUES  AND  KEYWORDS. 
THESE  SEARCHES  OCCUR  ACROSS  MULTIPLE  SECURITY  LEVELS,  SAVING  WATCHST ANDER 
TIME  AND  ALLOWING  MORE  TIME  FOR  ANALYSIS. 

-  DISSEMINATE  DAILY  AT/FP  SUPPORT  MESSAGE  TO  U.S.  AND  NATO  AUDIENCE  TAILORED  TO 
C2F/CSFL  RESPONSIBILITIES 

-  AUTO-DISTRIBUTE  ALL-SECURITY  LEVEL  MSG  TRAFFIC  AND  SCI  E-MAIL 


MSGID 

FROM 

SUBJECT 

151130Z  SEP  03 

USS  BLUE  RIDGE 

SUBJ/JOINT  MESSAGE  HANDLING  SYSTEM  (JMHS) 
REPLACEMENT 

-  POWERFUL  MESSAGE  HANDLING  SYSTEM  IS  THE  OSIS  EVOLUTIONARY  DEVELOPMENT 
(OED)  SYSTEM  THAT  WAS  RECENTLY  INSTALLED  IN  SUPPORT  OF  SCI/GENSER 
INTELLIGENCE  MESSAGE  HANDLING. 


MSGID 

FROM 

SUBJECT 

180901Z  SEP  03 

JAC 

MOLESWORTH 

OED  PROGRAM  SUPPORT 

-  REQUESTS  CONTINUATION  OF  OED  RDT&E,  OMN,  OPN  SUPPORT  DUE  TO  THE  CRITICALITY 


OF  OED  TO  THE  JAC’S  MISSION. 


MSGID 

FROM 

SUBJECT 

211846Z  AUG  03 

COMLANTFLT  / 
N2/N3 

OED  SUPPORT  TO  THE  FLEET 

-  COMLANTFLT  REQUIRES  CONTINUED  CONTACT  REPORTING  AND  REQUESTS  JFIC 

CONTINUE  TO  HOST  [OED]  AND  OPNAV  N612,  ONI-4  AND  PMW-157  CONTINUE  TO  REOURCE 
THIS  CRITICAL  SUPPORT  TO  THE  FLEET.” 


MSGID 

FROM 

SUBJECT 

030845Z  JUL  03 

C7F 

FLEET  BATTLE  EXPERIMENT  KILO  QUICKLOOK 

-  JOINT  FIRES. .  ..A  RAPIDLY  RECONFIGURABLE  AND  RELIABLE  TECHNOLOGY  THAT  CAN 
QUICKLY  MEET  SECURITY  APPROVALS  MUST  BE  IN  PLACE  SO  THAT  COALITION  PARTNERS 
CAN  ARRIVE  IN  AN  AOR  AND  QUICKLY  BECOME  PARTICIPANTS  IN  AN  EXISTING  FIRES 
NETWORK. 
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FLEET  GENERATED  REQUIREMENTS 


MSGID 

FROM 

SUBJECT 

281346ZMAR03 

CFFC  N6  /  N2 

FLEET  REQUIREMENTS  FOR  A  MULTI  LEVEL  SECURE 
(MLS)  SOLUTION 

-  IN  TODAY'S  ENVIRONMENT  OF  TIME  SENSITIVE  AND  COALITION  OPERATIONS,  A  MLS 
SYSTEM  IS  INCREASINGLY  IMPORTANT  TO  IMPROVE  COMMUNICATION  EFFICIENCY  AND 
INCREASE  SPEED  OF  INTELLIGENCE  EXCHANGE  AMONG  ALLIES  AND  COALITION 
PARTNERS 

-  A  SINGLE  NETWORK  EQUIPPED  WITH  COMMON  APPLICATIONS  THAT  HANDLES  AND 
AGGREGATES  DATA  OF  VARIOUS  SECURITY  LEVELS  ACROSS  BOTH  SCI  AND  COLLATERAL 
DOMAINS  WITHIN  AN  ACCREDITED  MLS  ARCHITECTURE  /  OPERATING  SYSTEM. 


MSGID 

FROM 

SUBJECT 

281159Z  MAR  03 

C2F/C3F 

NUMBERED  FLEET  TOP  TEN  INFORMATION 
TECHNOLOGY  REQUIREMENTS 

-  MULTIPLE  LEVEL  SECURITY  SHOULD  PROVIDE  THE  FULL  RANGE  OF  COLLABORATION 
CAPABILITIES  ACROSS  NUMEROUS  NETWORKS  OF  DIFFERENT  SECURITY  CLASSIFICATION 
LEVELS,  TO  INCLUDE  SEAMLESS  EXCHANGE  OF  EMAIL,  WEB  PRODUCTS,  FILE  SHARING 
AND  CHAT. 


MSGID 

FROM 

SUBJECT 

111450Z  MAR  03 

COMSECONDFLT 

SCI  NETWORK  SUPPORT  REQUIREMENTS 

-  TAILORED  MULTI-LEVEL  SECURITY  SUPPORT  TO  TACTICAL  UNITS 

MSGID 

FROM 

SUBJECT 

262206Z  FEB  03 

COMENTBATGRU 

REQUEST  FOR  OED  INSTALLATION 

-  REQUEST  TO  C2F  FOR  SUPPORT  OF  OED  INSTALLATION  ONBOARD  USS  ENTERPRISE  (CVN  65) 


MSGID 

FROM 

SUBJECT 

211942Z  FEB  03 

COMSECONDFLT 
(COORDINATED 
COMSECONDFLT 
/  COMTHIRDFLT 
MESSAGE) 

SEA  POWER-21  IMPLEMENTATION  MESSAGE  NR-3; 
OPERATIONAL  AGENT  REQUIRED  WARFIGHTING 
CAPABILITIES  LIST  (U) 

-  MULTI-NATIONAL  COMMAND  AND  CONTROL  INTELLIGENCE  INFORMATION 

MANAGEMENT,  ANALYSIS,  AND  FUSION  SUPPORT  TOOLS  MULTI-LEVEL  SECURITY 
STANDARDIZED  COALITION  IT  CONNECTIVITY” 


MSGID 

FROM 

SUBJECT 

101447ZDEC02 

COMSECONDFLT 

OSIS  EVOLUTIONARY  DEVELOPMENT  (OED) 

AFLOAT:  EVALUATION 

-  ENABLE  INTELLIGENCE  SUPPORT  TO  COALITION  OPERATING  ENVIRONMENTS 


-  ABILITY  TO  OPERATE  IN  THE  MULTI-NATIONAL  ENVIRONMENT 

-  ABILITY  TO  RECEIVE  AND  MANIPULATE  IMAGERY  ACROSS  SECURITY  DOMAINS 

-  MLS  DATABASE  TO  HAVE  HTML  DATA-CONTENTS  TAGS  AS  WELL  AS  SECURITY  LABELS 

-  ABILITY  TO  INTERFACE  WITH  COALITION  INTELLIGENCE  DATABASES 
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FLEET  GENERATED  REQUIREMENTS 


-  PRESERVE  THE  ORIGINAL  NATO  RELEASABILITY  OF  THIS  INFORMATION  AS  IT  IS  FUSED  IN 
AN  ALL-SOURCE  INTELLIGENCE  ENVIRONMENT. 


MSGID 

FROM 

SUBJECT 

132202ZAUG02 

COMTHIRDFLT 

JCSBG  INTELLIGENCE  LESSONS  LEARNED 

-  STRONGLY  ENDORSE  THE  CONTINUALLY  IDENTIFIED  FLEET  REQUIREMENT  FOR  A  MULTI- 

LEVEL  SECURITY  SYSTEM  AFLOAT 


MSGID 

FROM 

SUBJECT 

021820ZAUG02 

COMCARGRU  7 

EQUIPMENT  -  LACK  OF  A  MULTI-LEVEL  SECURITY 
SYSTEM  AFLOAT 

IDCLS/L/12373-20899/U// 

ORIG/CCG7/LCDR  GREG  HUSMANN 

-  TIMELY  EXCHANGE  OF  INTELLIGENCE  BETWEEN  MANY  COALITION  MEMBERS 


-  THE  REQUIREMENT  EXISTS  FOR  A  SINGLE  WORK  STATION  EQUIPPED  WITH  COMMON 
INTELLIGENCE  APPLICATIONS  ACROSS  THE  FULL  SPECTRUM  OF  POTENTIAL  SECURITY 
CLASSIFICATION  LEVELS 

-  CAPABLE  OF  PROCESSING  AND  EXCHANGING  DATA  AT  THE  DESIRED  CLASSIFICATION 
LEVEL  USING  STANDARD  APPLICATIONS: 


MSGID 

FROM 

SUBJECT 

180235Z  DEC  01 

COMSECONDFLT 

SCI  GCCS-M  LAN  UPGRADE  REQUIREMENTS 

-  AUTOMATED  MESSAGE  HANDLING  /  MULTI-SECURITY  LEVEL  INFORMATION 
MANAGEMENT 


o  SINGLE,  AGGREGATED,  MULTI-SECURITY  LEVEL  DATABASE  SUPPORT 
o  MULTI-SECURITY  LEVEL  WEB  SERVICES 

o  ALL-SECURITY-LEVEL  LAND/AIR  /MARITIME  (MERCHANT/SURFACE/ 
SUBSURFACE)  TRACK  MANAGER  WITH  HISTORY  AND  TREND  ANALYSIS 
CAPABILITY 

o  A  SECURITY  LAN  INTERFACE  BETWEEN  U.S.  AND  NATO/COMMMONWEALTH 
SYSTEMS. 


MSGID 

FROM 

SUBJECT 

211442ZMAY  01 

CINCLANTFLT 

N6A 

CINCLANTFLT  MULTI  SECURITY  LEVEL-MULTI 

LEVEL  SECURITY  (MSL-MLS)  FOCUS  WORKSHOP 
RESULTS 

-  MSL-MLS  SYSTEMS  MUST  PROVIDE: 


o  REDUCED  HULL,  MECHANICAL  AND  ELECTRICAL  (HM&E)  SHIPBOARD 
FOOTPRINT 

o  ABILITY  TO  SECURELY  EXCHANGE  DATA  BETWEEN  USERS/SYSTEMS  THAT 
PROCESS  DATA  ON  DIFFERENT  CLASSIFICATION  LEVELS 
o  ABILITY  FOR  MSL-MLS  TO  OPERATE  IN  BANDWIDTH  CONSTRAINED 
ENVIRONMENTS 

o  ABILITY  FOR  MSL-MLS  TO  OPERATE  IN  DEGRADED  ENVIRONMENT 


MSGID 

FROM 

SUBJECT 

272118ZFEB01 

COMSECONDFLT 

FLEET  REQUIREMENTS  FOR  MULTI  LEVEL 

NETWORKS 
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_ FLEET  GENERATED  REQUIREMENTS _ 

ACCELERATED  DEVELOPMENT  AND  FIELDING  OF  FULL  CONTENT-BASED  MLS  SOLUTIONS. 


Table  1.  Navy  CDS  Requirements  (Table  7,  Appendix  F) 

USS  Blue  Ridge  staff  members  specifically  requested  a  MLS  system  that 
provided  support  for  collaboration  capabilities  across  numerous  networks  of  differing 
security  classification  levels  and  IP  connectivity  to  bilateral  circuits,  to  include  seamless 
exchange  of  email,  web  browsing,  file  sharing  and  chat  services.  The  system  additionally 
was  required  to  provide  for  coalition  support  of  a  long-term  OTH-T  Track  archive  and 
Message  archive  for  Intel  analysis  (USS  Blue  Ridge,  151 130ZSEP  03). 


B.  ANALYSIS  OF  ALTERNATIVES 

An  analysis  of  numerous  systems  was  conducted  to  determine  the  best  solution  set 
for  the  USS  Blue  Ridge’s  requirements.  Although  this  analysis  is  not  the  subject  of  this 
thesis,  a  general  discussion  of  the  analysis  will  introduce  systems,  terms,  and  engineering 
concepts  and  thus  provide  background  for  the  afloat  installation  of  OED. 

The  first  step  in  determining  a  set  of  plausible  solutions  is  to  analyze  the  CDS 
spectrum  for  the  correct  technologic  approach.  As  discussed  above,  the  best  subset  of 
solutions  are  found  in  the  MLS  technology.  System-high  solutions  result  in  separate 
security  domains  that  can  be  bridged  by  operator  action  only.  That  action  is  frequently 
performed  over  an  air  gap  and  thus,  is  not  properly  audited.  Auditing  does  not  prevent 
security  violations  from  occurring  but  the  audit  log  does  allow  for  more  comprehensive 
troubleshooting  and  “clean-up”  if  a  security  violation  occurs. 

One  way  to  introduce  auditing  and  to  simplify  (even  to  the  point  of  automating) 
the  transfer  of  data  across  security  domains  is  the  implementation  of  guards  in  the 
architecture  (Kane,  2002).  This  approach  was  identified  above  as  MSL.  MSL  is  a  very 
favorable  solution  in  some  scenarios  but  there  are  still  issues.  The  guards  are  connecting 
two  or  more  system-high  security  domains  thus  introducing  all  the  issues  with  system- 
high  architectures  discussed  above.  The  guards  themselves  must  ensure  downgraded  data 
has  been  sanitized  to  the  security  level  of  the  destination  domain.  This  often  results  in 
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data  fields  being  eliminated  or  manipulated,  thus  resulting  in  loss  of  data,  data 
synchronization  issues  across  domains,  data  correlation  issues,  and  increased  data 
management.  There  is  a  cost  issue  with  MSL,  too.  The  common  MSL  architecture  has 
duplicative  architectures  in  each  domain  with  a  guard  between  domains.  Therefore,  it  is 
conceivable  that  an  architecture  consisting  of  five  servers  and  five  workstations  (a  total  of 
ten  “boxes”)  could  be  duplicated  for  every  coalition  domain  and  every  United  States 
security  domain  in  addition  to  the  guarding  devices  between  each  domain. 

The  best  alternative  is  an  MLS  solution.  MLS  allows  data  to  be  accessed  from 
multiple  classification  levels  while  being  persisted  at  a  specific  level  of  classification 
utilizing  labels  for  each  piece  of  data  (Myer  &  Patterson,  2003).  These  labels  maintain 
the  classifications  and  releaseability  infonnation  attributed  to  that  data.  Therefore, 
assuming  data  is  not  altered  while  being  accessed,  the  data  remains  at  its  original 
classification  level  and  does  not  have  to  pass  through  a  “guarding”  function  where  data 
loss/manipulation  may  occur.  The  use  of  labels  also  allows  for  bilateral  agreement 
compliance,  releaseability  rules  compliance,  and  the  ability  to  utilize  data  to  derive 
correlated  products  while  still  maintaining  the  original  classification  of  the  data  pieces. 
This  is  the  most  important  aspect  of  MLS  technology. 

In  order  to  better  understand  this  aspect,  one  must  first  look  at  the  three  states  of 
data  that  any  MLS  solution  must  address.  There  is  data  in  transit  and  that  state  is 
addressed  with  MLS  communications  (the  ability  to  pass  data  at  different  security  domain 
levels  on  one  network  or  communications  path).  The  second  state  of  data  is  data  at  rest; 
for  example,  data  in  storage.  This  state  is  addressed  by  an  MLS  database  that  allows  data 
at  different  security  levels  to  be  stored  in  one  database.  The  last  state  of  data  is  “in 
process.”  Data  in  process  is  data  undergoing  some  operation.  It  could  be  an  operation  as 
simple  as  property  comparison  or  as  critical  as  correlation  and  fusion  of  a  large  set  of 
data.  Today’s  Warfighters  rely  on  C2I  systems  to  process  the  enormous  amount  of  data 
received  from  sensors  in  order  to  gain  situational  awareness  of  the  battle  space  around 
them.  It  is  virtually  impossible  for  Warfighters  to  carry  out  the  task  of  correlating 
incoming  data  in  order  to  maintain  a  Common  Operational  Picture  (COP)  that  can  be 
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shared  around  the  battle  space  and  up  and  down  the  chain  of  command.  Any  CDS 
solution  must  address  the  ability  to  handle  the  “in  process”  state  of  data  in  order  to  give 
the  Warfighters  the  products  they  need  to  fight  the  war.  There  is  only  one  accredited 
MLS  C2I  system  in  DoD  and  that  system  is  OED.  OED  allows  the  Warfighter  to  apply 
correlators  on  the  entire  set  of  data  available  to  the  Warfighter  in  spite  of  what  security 
domain  he  may  be  working  in  because  OED’s  correlators  work  against  an  MLS  database 
that  contains  every  piece  of  data  received  in  every  security  domain.  This  eliminates 
disparate  COPs  in  different  security  domains.  It  also  prevents  incorrect  correlation  found 
in  a  system-high  architecture  because,  in  that  architecture,  the  correlator  working  at  the 
SECRET  level  is  not  aware  of  TOP  SECRET  data  in  this  architecture.  The  Warfighter  is 
relying  on  a  correlation  process  applied  on  a  subset  of  the  data.  Even  when  an  MSL 
guarding  solution  is  added  to  the  system-high  architecture,  the  data  loss  found  in  passing 
data  through  a  guard  still  prohibits  the  correlator  from  utilizing  the  entire  set  of  data 
available  (Newcomb,  2003). 

Although  it  would  appear  the  key  system  to  a  successful  Coalition  architecture  is 
OED  afloat,  there  are  other  systems  and  issues  to  consider.  The  following  systems  were 
selected  for  the  USS  Blue  Ridge  architecture  in  the  analysis  of  alternatives: 

1.  Global  Command  and  Control  System  -  Maritime 

Global  Command  and  Control  System  -  Maritime  (GCCS-M)  is  the  Command 
and  Control  component  of  the  Navy's  Command,  Control,  Communications,  Computers 
and  Intelligence/Surveillance  and  Reconnaissance  (C4ISR)  systems  (GCCS-M  ORD, 
1999).  The  system  supplies  information  that  aids  Navy  Commanders  in  a  full  range  of 
tactical  decisions.  In  functional  terms,  GCCS-M  fuses,  correlates,  filters,  and  maintains 
raw  data  and  displays  image-building  information  as  a  tactical  picture.  Specifically,  the 
system  displays  location  of  air,  sea,  and  land  units  anywhere  in  the  world  and  identifies 
whether  those  units  represent  friendly,  neutral  or  enemy  forces.  It  operates  in  near  real¬ 
time  and  constantly  updates  unit  positions  and  other  situational  awareness  data.  GCCS-M 
also  records  the  data  in  appropriate  databases,  and  maintains  a  history  of  the  changes  to 
those  records.  The  user  can  then  use  the  data  individually  or  in  concert  with  other  data  to 
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construct  relevant  tactical  pictures,  using  maps,  charts,  map  overlays,  topography, 
oceanographic,  meteorological,  imagery  and  all-source  intelligence  information  all 
coordinated  into  the  COP.  The  picture  is  referred  to  as  common  because  once  constructed 
it  can  be  shared  with  joint  users  who  need  the  information.  Supplied  with  this 
information,  Navy  and  Joint  Commanders  can  review  and  evaluate  the  general  tactical 
situation,  detennine  and  plan  actions  and  operations,  direct  forces,  synchronize  tactical 
operations,  and  integrate  force  maneuver  with  firepower.  The  system  operates  in  a  variety 
of  environments  and  supports  joint,  coalition,  and  allied  forces  (Rodriguez,  2004).  A 
graphical  depiction  of  GCCS-M  is  provided  by  Figure  1. 
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UCP:  Universal  Communications 
Processor 

TDBM:  Track  Data  Base  Manager 
ISDS:  Intelligence  Support  Data  Services 
MIDB:  Modernized  Intelligence  Data 
Base 

ITS:  Imagery  Transformation  Services 


Figure  1.  GCCS-M  Architecture  (From  Rodriguez,  2004) 


2.  Radiant  Mercury 

Radiant  Mercury  (RM)  is  a  certified  and  accredited  system  that  provides  a  large 
array  of  CDS  services  to  the  Warfighter.  RM  provides  for  automated  sanitization  and 
guarding  between  security  boundaries,  downgrading  services  to  allow  an  operator  to 
move  data  into  a  lower  classification  level,  format  transliteration  (automatically  change 
message  formats,  units,  etc.),  tools  to  facilitate  releaseability  to  our  Coalition  partners, 
complete  audit  records  for  information  assurance  and  security,  and  post-event 
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reconstruction  tools.  RM  is  in  the  Coalition  afloat  architecture  in  two  roles:  a 
sanitization  and  guarding  tool  between  the  SCI  and  General  Service  (GENSER  or 
SECRET  and  below  security  levels)  GCCS-M  systems  and  as  a  downgrading  tool  inside 
the  OED  system  (Kane,  2002). 

3.  Ocean  Surveillance  Information  System  (OSIS)  Evolutionary 
Development  (OED) 

OED  passed  operational  testing  in  1998  and  has  successfully  completed  security 
accreditation  48  times  since  initial  fielding.  It  is  fielded  at  the  Joint  Intelligence  Centers 
in  Hawaii  and  Norfolk  and  at  the  Joint  Analysis  Center  at  Molesworth,  England.  It  is 
also  the  foundation  of  the  C2I  architectures  in  four  allied  countries  (Newcomb,  2004). 
The  system  supports  command,  control  and  intelligence  assessment,  including  indications 
and  warning  (I&W)  and  power  projection;  maintains  dynamic  databases  to  support  a 
common  air,  land,  sea  and  littoral  battlefield  picture  using  ground  force  and  maritime 
symbology;  provides  access  to  multiple  communications  networks  for  inter-force 
compatibility  and  interoperability  that  support  database  sharing  and  data  analysis;  and 
supports  Joint  Task  Force  commanders,  Theater  Commanders  (COCOMs),  service 
components  and  subordinate  units.  OED  operates  in  an  MLS  DII  COE  architecture, 
providing  local  and  global  networking  for  on-demand  services  and  timely  response  to 
consumer  requests  for  fused  intelligence.  OED  supports  joint  Air  Force,  Army,  Navy, 
Marine  Corps,  and  Coast  Guard  operations  with  additional  tasking  to  support  counter¬ 
terrorism,  counter-narcotics  and  allied  coalition  operations.  Figure  2  depicts  a  line 
drawing  of  the  connectivity  provided  in  a  generic  OED  architecture. 
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•  OED  provides  information  management  tools  optimized  for  dealing  with 
multiple  security  domains  and  large  data  rates 


Figure  2.  Generic  OED  Architecture  (From  Fish,  2004) 


4.  Global  Command  and  Control  Systems  -  Integrated  Imagery  and 
Intelligence  (GCCS-I3) 

Global  Command  and  Control  Systems  -  Integrated  Imagery  and  Intelligence 
(GCCS-I3)  provides  COP-centric  intelligence  and  imagery-related  capabilities  developed 
by  the  four  military  Services  and  selected  Agencies  in  response  to  Joint  Warfighter 

-j 

requirements.  Through  the  GCCS- 1  integration  process,  these  tools  provide  Intelligence 
Support  to  Operations  seamlessly  within  the  GCCS  family  of  systems. 

GCCS-  I  enhances  the  operational  commander’s  situational  awareness  by 
providing  a  standard  set  of  integrated,  linked  tools  and  services  which  give  ready  access 
to  imagery  and  intelligence  directly  from  the  operational  display.  This  capability  is  used 
to  combine  the  vast  resources  of  the  tactical,  operational,  and  national  intelligence 


21 


community  with  critical  command  and  control  information.  This  results  in  an 
unprecedented  level  of  streamlined  intelligence  support  to  operations. 


GCCS-  I3  gives  tactical  operators  and  intelligence  analysts  direct  access  to  the 
nationally  produced  Modernized  Integrated  Database  (MIDB)  for  Order  of  Battle  (OOB) 
data,  weapons  systems’  characteristics  and  performance  information,  and  national 
imagery.  GCCS-  I  also  gives  those  users  the  capability  to  integrate  locally  collected 
tactical  imagery  and  other  intelligence  with  national  and  theater-produced  intelligence. 
This  intelligence  can  be  plotted  directly  on  operational/tactical  displays  alongside 
continuously  updating  operational  and  operational-intelligence  information,  providing 
tactical  operators  and  intelligence  analysts  vastly  improved  knowledge  of  the  battle  space 

•5 

(Newcomb,  2004).  Figure  3  identifies  the  Joint  components  of  the  GCCS-I  suite  of 
intelligence  and  imagery  tools. 


NEW  INTEGRATED  CAPABILITY 


Joint  Targeting  Toolbox 

JTT  (Joint) 


Improved  Many -on-Many 

IMOM  (USAF) 


C2PC 

(USMC) 


Joint  Threat  Analysis  Tools/ 
Ground  Template  Toolkit 

JTAT/GTT  (USA) 


Collection  Mission  Management  Application 

CMMA  (USN) 


Figure  3.  GCCS-I3  v3.6  applications  from  the  various  Services  (From 

Newcomb,  2004) 
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5.  Defense  Information  Infrastructure  Common  Operating  Environment 

The  Defense  Infonnation  Infrastructure  Common  Operating  Environment  (DII 
COE)  provides  a  foundation  for  building  interoperable  systems  through  the  use  of 
reusable  software  components  (building  blocks).  The  DII  COE  can  be  characterized  as  a 
number  of  things,  depending  upon  one's  point  of  view.  It  is  an  architecture,  a  collection 
of  reusable  software  elements,  a  software  infrastructure,  and  a  set  of  guidelines  and 
standards.  More  importantly,  however,  is  that  it  provides  a  common  platform  (or 
foundation)  for  building  interoperable  systems.  Therefore,  one  could  think  of  the  DII 
COE  as  a  component  of  system  architecture,  as  it  is  an  implementation  of  the  Joint 
Technical  Architecture  (JTA).  One  could  also  think  of  the  DII  COE  as  an  approach  to 
software  development  —  how  to  go  about  building  interoperable  systems  on  a  common 
platform.  Finally,  it  is  important  to  realize  that  the  DII  COE  is  not  a  system,  but  a  set  of 
building  blocks  from  which  a  system  can  be  built.  GCCS,  Global  Combat  Support 
System  (GCSS),  and  service  unique  programs  (like  the  Air  Force’s  Theater  Battle 
Management  Command  and  Control  Systems  (TBMCS))  are  building  their  systems  on 
top  of  the  DII  COE  foundation  (Sardosky,  1997). 

DII  COE  is  a  software  infrastructure,  a  collection  of  reusable  software 
components,  a  set  of  Application  Program  Interfaces  (APIs),  and  a  series  of  specifications 
and  standards  for  developing  interoperable  systems. 

The  DII  COE  taxonomy  defines  two  layers  of  reusable  software  components: 
infrastructure  services,  which  include  the  DII  COE  kernel  services,  and  the  underlying 
COTS  operating  systems.  Infrastructure  services  address  the  movement  of  data  through 
the  network  and  include  distributed  computing  and  web  services.  The  kernel  provides 
low-level  services,  including  a  desktop  environment,  runtime  tools,  and  basic  system  and 
security  administration.  Common  support  applications  provide  services  that  address 
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common  command  and  control  functionality,  for  example,  mapping  and  message 
processing  (Sardosky,  1997). 

Standard  APIs  provide  the  interfaces  between  mission  applications  and  reusable 
software  components  of  the  DII  COE.  Mission  applications  are  developed  on  top  of  the 
DII  COE  and  provide  mission  domain  specific  functionality. 

Since  GCCS-M,  GCCS-  I3,  and  OED  are  all  DII  COE  based  systems,  one 
alternative  addressed  was  the  integration  of  OED  and  the  GCCS-  I  suite  of  tools  that 
could  then  be  utilized  by  the  GCCS-based  systems  such  as  GCCS-M.  This  alternative  is 

•2 

very  promising  because  both  OED  and  GCCS-  I  are  DII  COE  systems  utilizing  the 
Hewlett  Packard  UNIX  (HPUX  10.20)  kernel.  Both  rely  on  the  MIDB  database  for 
intelligence  data,  the  Imagery  Transformation  Services  database  for  imagery,  and  the 
Track  Database  Manager/Track  Management  System  (TDBM/TMS)  for  tracks.  This  is 
critical  since  OED  has  MLS-enabled  both  the  TDBM  and  the  MIDB.  From  a  systems 

•5 

engineering  perspective,  another  viable  alternative  would  be  to  integrate  GCCS-  I 

•2 

applications  into  the  OED  system.  Since  the  GCCS- 1  “system”  is  truly  just  a  collection 
of  applications  operating  on  a  common  kernel,  the  integration  of  these  applications  upon 

OED’s  kernel  is  relatively  simple.  Also,  this  allows  the  developer  to  allow  the  operator 

•2 

to  utilize  the  GCCS-  I  tools  in  a  trusted  fashion  to  add  value  to  the  trusted  intelligence 
data.  This  is  critical  to  optimizing  the  functionality  of  the  GCCS-  I  tools  and  thus, 
getting  the  most  out  of  the  trusted  data. 

From  the  Fleet  perspective,  it  is  important  to  review  the  requirements  the  Fleet 
has  levied  on  acquisition  world.  The  Fleet  has  asked  for  MLS  functionality  now  (as 
referenced  in  Table  1)  and  the  only  MLS  C2I  solution  available  to  the  Joint  Warfighter  is 
OED.  The  Fleet  has  also  asked  for  increased  capability  in  the  GCCS-I3  toolset  (CFFC 
N2/N6,  281346ZMAR03).  The  OED  and  GCCS-I3  integration  solution  provides  the 
Fleet  with  the  MLS  capability  they  desire  and  the  GCCS-I  value-added  functionality 
they  desire.  This  is  a  very  good  approach  from  the  Fleet  perspective. 

Another  approach  is  the  integration  of  OED’s  MLS  technology  into  GCCS-  I  . 

This  approach,  again,  makes  sense  from  a  systems  engineering  perspective.  The  original 
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concept  behind  OED  was  the  implementation  of  MLS  onto  a  DII  COE-based  system. 
Plus,  this  approach  would  allow  the  MLS  capabilities  to  be  implemented  on  the  current 
DII  COE  and  on  the  current  operating  system  (Solaris).  However,  due  to  the 
“obsolescence”  (Myerriecks,  Defense  Infonnation  Systems  Agency  (DISA)  Chief 
Technology  Officer,  2004)  of  the  GCCS  architecture  and  the  push  to  provide  enterprise 
services  in  the  next  generation  C4I  system  (the  Joint  Command  and  Control  System 
(JC2)),  the  web  services  found  in  JCDX  (OED’s  successor  and  the  “CDS  cornerstone” 
(M.  Cherry,  comments  at  the  JCDX  Horizontal  Fusion  Quarterly  Status  Review,  January 
16,  2004)  of  the  future  C2I  architectures)  were  deemed  a  better  alternative  to  re¬ 
engineering  the  DII  COE. 

6.  Multi-Level  Thin  Clients 

One  critical  issue  of  presenting  multiple  security  levels  to  the  Warfighter  is  the 
number  of  monitors  required  to  view  each  level  that  the  Warfighter  is  authorized  to 
access.  This  could  result  in  four  or  five  monitors  on  one  desk  for  one  operator  to  utilize. 
Of  course,  this  presents  a  space  and  power  issue  plus  an  operational  issue  of  trying  to 
correlate  all  the  data  manually  across  the  displays.  One  solution  for  space  and  power 
constraints  is  a  multi-level  thin  client  (MLTC)  operator  position.  The  MLTC  fuses 
several  secure  networks  into  one  slim  workstation  consisting  of  a  monitor  and  a  thin 
client  interface.  By  design,  the  MLTC  replaces  the  multiple  monitors  and  PCs  on  a 
user’s  desk,  and  lowers  hardware  maintenance  requirements.  It  also  reduces  the  power 
footprint  by  not  having  to  plug  in  multiple  PCs  and  it  helps  with  system  administration. 
With  the  removal  of  the  PCs,  everything  can  be  controlled  from  a  server  (SPAWAR, 
2002). 

By  design,  MLTC  terminals  have  no  transportable  storage  capability  such  as  flash 
memory  stick,  CD-ROM,  or  even  floppy  disk  devices.  By  reducing  access  points,  the 
network  becomes  more  secure  because  users  cannot  introduce  unauthorized  media  on  the 
network.  Based  upon  individual  user  clearance  levels,  operators  have  access  to  multiple 
and  independent  networks  at  once  in  separate  windows  on  the  same  monitor,  with  data 
pulled  from  widely  disparate  enclaves.  With  the  use  of  “smart”  Common  Access  Cards 
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(CACs),  users  can  move  between  MLTC  clients  without  having  to  reset  their  profiles. 
This  saves  users  time  as  they  move  from  workstation  to  workstation  in  support  of  the 
mission.  An  additional  benefit  to  the  system  administrators  is  the  ability  to  install 
application  software  on  the  server  vice  on  multiple  PCs.  MLTC  clients  then  access  the 
server  to  provide  the  tools  and  functions  of  the  various  applications.  A  representative 
MLTC  architecture  is  represented  in  Figure  4. 


Figure  4.  General  MLTC  architecture  reflecting  the  use  of  session  servers  for 

each  domain  (From  SPAWAR,  2002) 

7.  Combined  Enterprise  Regional  Information  Exchange  System 
(CENTRIXS) 
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CENTRIXS  is  a  global  multinational  infonnation  sharing  network  fielded  to 
provide  a  common  network  for  coalition  forces  to  share  data.  CENTRIXS  is  web-centric 
and  COTS  oriented.  Implementation  focused  on  fielding  core  information  services  first: 
e-mail  with  attachments,  web-browser-based  data  access,  and  file  sharing.  Other  required 
services,  including  collaboration  and  near-real  time  data  access,  will  be  enabled  as  the 
network  matures.  To  the  extent  possible,  CENTRIXS  will  subsume  and  consolidate 
existing  stove-piped  coalition  networks  as  part  of  a  single,  unified  system  (Miller,  2003). 

The  basic  mission  of  CENTRIXS  is  to  support  intelligence  and  operations 
information  exchange  and  sharing  through  reliable  communications  connectivity,  data 
manipulation,  and  automated  processes  for  bilateral  or  multi-lateral  database  access  and 
information  exchange  among  cooperating  nations  and  international  organizations. 
Specifically,  the  system  provides  Combatant  Command  decision  makers,  commanders, 
and  units  with: 

•  the  COP 

•  Electronic  mail  (e-mail)  with  attachments 

•  Common  Intelligence  Picture  (CIP) 

•  Synchronization  of  the  actions  of  air,  land,  sea,  space,  and  special  operations 
forces 

•  Web-enabled  services,  office  automation,  and  bulletin  boards 

•  Secure  Voice 

•  Support  for  US  and  coalition  exercises 

CENTRIXS  uses  existing  communications  infrastructures,  such  as  the  SIPRNET, 

whenever  possible.  The  system  employs  NSA- Approved  Type-1  encryption  devices  and 

sends  an  encrypted  signal  from  Area  of  Responsibility  (AOR)  locations  (strategic  or 

tactical)  to  either  a  Gateway  Forward  Point  of  Presence  (FPoP)  site  or  to  the  command 

headquarters.  This  is  accomplished  using  four  different  basic  types  of  network 

configurations.  The  first  type  is  a  bilateral  network,  in  which  one  nation  and  the  US 

participate  in  sharing  infonnation.  The  second  type  is  the  FPoP,  in  which  an  entire  server 

suite  is  installed  in  the  region  and  acts  as  a  hub  or  gateway  for  CENTRIXS  users  in  the 

AOR.  The  third  type  is  the  deployable  CENTRIXS  network,  which  provides  just  the 
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essentials  necessary  to  complete  the  mission:  two  servers  and  12  laptops  stored  in  transit 
cases  for  mobility.  The  deployable  CENTRIXS  can  access  the  CENTRIXS  network  by 
tunneling  through  the  SIPRNet  or  another  available  communications  path.  The  fourth 
type  is  a  command  headquarters  configuration.  The  command  headquarters  suite 
connects  to  any/all  of  the  other  three  configurations  referenced  above  and  contains  a  suite 
of  servers  that  provides  CENTRIXS  services.  (JITC,  2004).  The  afloat  Coalition 
architecture  for  CENTRIXS  Block  I  is  shown  in  Figure  5. 
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Figure  5.  CENTRIXS  Block  I  Coalition  Architecture  (From  Miller,  2003) 

C.  AFLOAT  ARCHITECTURE 

After  extensive  research  and  analyses,  the  SPAWAR  team  determined  the  best 
approach  for  a  coalition  architecture  afloat  was  a  combination  of  OED,  GCCS-M,  RM, 
MLTC,  and  CENTRIX  (also  known  as  the  Coalition  Wide  Area  Network  (COWAN)  at 
that  time).  This  combination  is  depicted  in  Figures  6  (the  CENTRIXS/COWAN 
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architecture  with  MLTC)  and  7  (the  OED  architecture  connected  to  the  COWAN/MLTC 
architecture).  In  this  architecture,  there  are  two  OED  systems  installed  -  one  on  the  SCI, 
or  “high”  side,  and  one  on  the  GENSER,  or  “low”,  side.  Both  OED  systems  provide 
MLS  services  to  the  U.S.  Warfighters  on  the  high  and  low  sides  via  the  JWICS 
communications  channel  on  the  high  side  and  via  the  SIPRNET,  GCCS-M,  MLTC,  and 
COWAN/CENTRIXS  communication  links.  Support  to  the  Coalition  Warfighters  is  also 
available  on  the  high  side  with  BISON  and  STONEGHOST  communications  and  on  the 
low  side  with  COWAN/CENTRIX  networks.  The  communications  involved  in  the  CDS 
architecture  are  listed  in  Table  2.  Although  this  proposed  architecture  provided  the  best 
alternative  for  an  afloat  architecture  by  addressing  cross  domain  solutions  for  data  at  rest, 
in  transit,  and  in  process;  the  actual  architecture  installed  did  not  match  this  proposal. 
That  issue  will  be  explored  in  greater  detail  in  Chapter  4’s  discussion  of  the  installation 
of  the  OED  TEMPALT.  An  understanding  of  the  TEMPALT  process  is  also  very 
beneficial  to  gathering  lessons  learned  from  the  OED  installation  on  board  LCC-19 
(Brenneman  &  Kwiatkowski,  2003  and  Miller,  2003). 
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Figure  6.  CDS  Afloat  Architecture,  part  1:  CENTRIXS/COWAN  architecture 
with  MLTC(From  Brenneman,  2003  and  Miller,  2003) 
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Figure  7.  Afloat  CDS  Architecture,  part  2:  OED  Servers  and  interfaces  (From 
Brenneman  &  Kwiatkowski,  2003  and  Miller,  2003) 


Communications  Name 

Definition 

Comments 

JWICS 

Joint  Worldwide 

Intelligence 

Communications  System 

SCI  network. 

STONEGHOST 

N/A 

Used  by  close  Allies  for  SCI 
intelligence 

OTCIXS 

Officer  in  Tactical 

Command  Information 
Exchange  Subsystem 

Use  for  GCCS-M  Track  data 
(i.e.,  Contact  Broadcast) 

AUTODIN 

Automatic  Digital  Network 

Older  network  for  message 
traffic,  used  with  Allies 

COWAN  A,  C,  J,  K 

Coalition  Operational  Wide 
Area  Network  Allied, 
Coalition,  Japan,  Korea 

Different  COWANs  used  for 
different  bilateral 
agreements 

SIPRNET 

Secret  Internet  Protocol 
Router  Network 

US  Only,  GENSER  only 

TRE 

Tactical  Receive  Equipment 

SCI  intelligence  reporting 
channel 

Table  2.  Major  Communications  channels  in  CDS  Architecture  (From  Brenneman  & 

Kwiatkowski,  2003  and  Miller,  2003) 
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III.  NAVSEA  SHIPBOARD  INSTALLATION  PROCESS 


A.  INTRODUCTION  OF  INSTALLATION  REQUIREMENTS 

This  section  discusses  requirements  for  Space  and  Naval  Warfare  Command 
(SPAWAR)  program  alterations  in  conjunction  with  the  Naval  Sea  Systems  Command 
(NAVSEA)  Fleet  Modernization  Program  (FMP)  for  alterations  to  Navy  platforms. 
NAVSEA  maintains  detailed  instructions  for  accomplishing  alterations  to  ships  and 
equipment  specified  in  the  Fleet  Modernization  Program  Management  and  Operations 
Manual  (NAVSEA,  2002). 

The  FMP  Shipboard  Installation  process  (hereafter  referred  to  as  the  FMP 
process)  was  established  to  provide  a  structure  for  the  orderly  identification,  approval, 
design,  planning/programming,  budgeting,  and  accomplishment  of  improvements  that 
increase  the  capability  or  reliability  of  a  ship  to  perform  its  assigned  mission  in 
accordance  with  OPNAVINST  4720.2G  (CNO,  1995).  The  FMP  process  addresses 
different  installation  alternatives  to  shipboard  configurations.  The  alternatives  available 
to  SPAWAR  programs  include  permanent  ship  alterations,  temporary  ship  alterations, 
hardware  field  changes  or  software  engineering  changes,  defined  in  SPAWARINST 
4720. 3C  (SPAWAR,  1998).  More  detailed  discussion  for  each  of  these  alteration  options 
follows  in  the  remainder  of  this  introduction  (Nowicki,  2004). 

A  permanent  Ship  Alteration  (SHIPALT)  is  required  when  the  proposed  change 
results  in  any  of  the  following  five  conditions  (NAVSEA,  2002): 

a.  Alteration  upgrades  existing  systems  or  provides  additional  capability  that 
necessitates  changes  in  fonn,  fit,  or  function  to  component  parts  of  the  ship. 

b.  Alteration  yields  increased  power  adjustments 

c.  Alteration  requires  additional  heating,  ventilation,  or  air  conditioning  (HVAC) 

d.  Alteration  requires  additional  cooling  (water  cooling) 

e.  Alteration  results  in  changes  to  external  cabling 
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If  the  alteration  is  deemed  temporary,  the  temporary  alteration  (TEMP ALT) 
process  may  be  used.  A  TEMP  ALT  is  any  alteration  that  provides  new  or  improves 
existing  capabilities  on  a  temporary  basis  supporting  Research  Development,  Test  and 
Evaluation  (RDT&E)  alterations,  or  military  exercise,  or  mission  requirements.  The 
purpose  for  these  alterations  is  to  demonstrate  and  test  new  concepts  while  evaluating 
effectiveness  in  an  operating  environment.  TEMP  ALTS  are  constrained  to  a  period  of 
less  than  one  year,  or  scheduled  for  a  platform’s  single  operational  deployment 
(NAVSEA,  2002). 

If  a  pennanent  alteration  change  does  not  fall  into  the  categories  (a  through  e) 
above,  then  the  Field  Change  (FC)  or  Engineering  Change  (EC)  alternatives  and  their 
reduced  documentation  requirements  are  appropriate.  The  Field  Change  (FC)  process  is 
applicable  for  internal  changes  (mechanical  and/or  electrical)  to  an  equipment  rack  or 
system  assembly  as  long  as  no  external  adjustments  are  required  to  a  ship’s  configuration. 
The  Engineering  Change  (EC)  process  should  be  used  if  the  product  is  a  software  release 
or  upgrade  (NAVSEA,  2002).  Figure  8  identifies  a  process  flow  to  detennine  the 
appropriate  type  of  alteration. 
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The  focus  for  this  research  is  to  detail  the  various  stakeholders  and  activities 
involved  in  TEMP  ALT  development  and  NAVSEA  approval  from  a  SPA  WAR  program 
office  (SPAWAR  PMW)  perspective,  with  assistance  from  the  Design  Support  Center 
(SPAWAR  04R-3)  and  the  Battle  Force  Manager  (SPAWAR  04F).  The  discussion  in 
the  remainder  of  this  chapter  overviews  standard  practices  and  timelines  associated  with 
design,  pre-planning,  installation,  and  completion  reporting  phases  for  surface  ship 
modifications.  Chapter  4  discusses  the  actual  process  flow  and  lessons  learned  associated 
with  TEMP  ALT  approval  for  an  OED  SCI  MLS  ARCHITECTURE  on  LCC-19  (USS 
BLUE  RIDGE). 


B.  STAKEHOLDER  ROLES  AND  RESPONSIBILITIES 

Specific  roles  and  responsibilities  associated  with  the  primary  stakeholders  in  the 
TEMP  ALT  process  are  delineated  in  the  FMP  manual  (NAVSEA  2002),  Volume  1, 
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Subsection  9-10.7  (reference  Appendix  A)  for  sponsoring  activity,  SPM  and  TYCOM 
entities.  A  high-level  overview  of  these  responsibilities  is  offered  below. 

The  SPAWAR  sponsoring  activity,  the  SPAWAR  PMW  along  with  assistance 
from  the  SPAWAR  Battle  Force  Manager  (SPAWAR  04F)  and  the  SPAWAR  Design 
Service  Center  (SPAWAR  04R-3)  has  responsibility  for  the  activities  associated  with  the 
planning  and  development  of  the  items  listed  below  (White,  2004). 

a.  Installation  scheduling  and  verification  of  ship(s)  availability 

b.  Non-Standard  Install  Offer  Message 

c.  TEMP  ALT  Change  Control  Proposal  (TCCP) 

d.  Plan  of  Action  and  Milestones  (POA&M). 

e.  TEMP  ALT  Justification/Cost  Form  (TJCF) 

f.  Final  TEMP  ALT  Data  Package  (Detailed  in  Table  3) 

g.  Funding  for  TEMAPLT  pre-installation,  installation,  operational  and  removal 
phases 

The  NAVSEA  Ships  Program  Manager  (SPM)  is  responsible  for  the  review  and 
approval  for  deliverables  relative  to  the  TJCF,  POA&M,  ILS  Certification  and  the 
TEMP  ALT  Data  Package.  The  applicable  Planning  Yard  supports  the  SPM  in  reviewing 
the  TEMPALT  Data  Package  installation  drawings  to  assess  impacts  to  the  ships 
configuration. 

The  Fleet  TYPE  Commander  (TYCOM)  has  responsibility  for  final  review  and 
authorization  of  the  Non-Standard  Install  Offer  Message  and  the  TEMPALT  Data 
Package  forwarded  from  the  SPM. 

C.  TEMPALT  PHASES 

A  TEMPALT  can  be  decomposed  to  four  phases  over  its  life  cycle.  The  four 
primary  activities  are  detailed  in  the  remainder  of  this  section  for  1)  alteration 
development,  2)  installation  planning,  3)  installation  completion,  and  4)  alteration 
removal  (Logg,  2004). 
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1.  TEMP  ALT  Design  Phase  Activities 

The  design  phase  for  a  TEMP  ALT  starts  with  an  emergent  requirement  to  field 
and  demonstrate  new  capabilities  in  an  operational  shipboard  environment  and  when 
successful  concludes  with  a  TYCOM  authorization  to  begin  installation  activities.  The 
activities  are  best  illustrated  in  two  phases.  The  first  phase  encompasses  activities 
associated  with  ship  selection  and  notification  to  the  TYCOM  for  approval  to  proceed 
with  TEMP  ALT  development.  The  process  flow  for  alteration  authorization  is  shown  in 
Figure  9.  After  TYCOM  authorization  is  obtained,  the  second  phase  is  an  iterative 
process  for  detailed  alteration  disclosure  between  SPAWAR  representatives  and  external 
approval  entities.  The  process  flow  for  the  alteration  approval  is  shown  in  Figure  10. 

To  assist  with  clarity,  the  activities  shown  in  Figures  9  and  10  references 
SPAWAR  processes  with  blue  rectangular  process  symbols  and  external  reviews  with 
yellow  diamond  shaped  process  symbols. 
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Figure  9.  TYCOM  Authorization  for  TEMPALT  Development 

The  SPAWAR  Program  Manager,  Warfare  (PMW)  program  office  (hereafter 
referred  to  as  SPAWAR  PMW)  selects  the  platform(s)  intended  to  receive  the  TEMPALT 
and  verities  the  ship’s  availability  by  working  with  the  appropriate  SPAWAR  Battle 
Force  Manager  (BFM),  or  SPAWAR  04F.  If  the  TEMPALT  scheduling  impacts  Battle 
Force  Interoperability  (BFI)  the  SPAWAR  BFM  prepares  documentation  demonstrating 
that  the  alteration  will  not  interfere  with  the  BFI  and  prepares  a  submission  to  the  Battle 
Force  electronic  Change  Control  Board  (eCCB)  to  obtain  Fleet  Commander  (FLTCOM) 
approval  for  the  alteration  (SPAWAR,  2004). 
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After  availability  is  established,  the  SPAWAR  PMW  prepares  and  submits  a  Non- 
Standard  Install  Offer  Message  to  the  TYCOM  for  approval  to  proceed  with  TEMP  ALT 
development  and  ship  check  activities.  The  minimum  timeline  to  obtain  this  approval  is 
fourteen  weeks  prior  to  installation  start  to  allow  adequate  time  for  the  documentation 
reviews  that  follow. 


A 


Figure  10.  TYCOM  Authorization  for  TEMP  ALT  Installation 


After  authorization  is  received  from  the  TYCOM  the  SPAWAR  PMW 
commences  to  develop  a  TEMP  ALT  Change  Control  Proposal  (TCCP)  to  overview  the 
impact  to  the  ship  in  terms  of  the  proposed  alteration  modifications  and  a  Plan  of  Action 
and  Milestones  (POA&M)  to  document  the  proposed  installation  schedule.  After  these 
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documents  are  submitted  the  SPAWAR  PMW  starts  to  develop  the  TEMP  ALT  Data 
Package. 

The  TEMP  ALT  Justification/Cost  Form  (TJCF)  is  developed  by  SPAWAR  04R-3 
from  information  provided  in  the  TCCP  for  impacts  to  the  ship  and  alteration  costs.  The 
draft  TJCF  is  reviewed  and  signed  by  the  SPAWAR  PMW  and  then  passed  to  the  SPM 
for  review  and  signoff.  The  SPM  then  assigns  a  TEMP  ALT  Number  to  the  alteration  and 
inputs  pertinent  information  from  the  TJCF  into  the  Navy  Data  Environment  -  Navy 
Modernization  (NDE-NM)  database  (Logg,  2004). 

Development  of  the  TEMP  ALT  Data  Package  is  carried  out  directly  by  the 
SPAWAR  PMW  or  via  tasking  to  design  support  agents  at  SPAWAR  Systems  Center 
Charleston  (SPAWARSYSCEN-CHAS)  and/or  SPAWAR  Systems  Center  San  Diego 
(SPAWARSYSCEN-SD).  The  design  agents  schedule  a  ship  check  to  support  the  proper 
development  of  installation  drawings  and  when  the  drawings  are  completed  they  are 
submitted  to  the  Planning  Yard  for  review  comments.  These  drawings  detail  system 
specific  space  adjustments,  cable  wiring  and  interfaces  to  other  systems,  and  the  electrical 
signal  flow  for  each  cable. 

A  Final  TEMP  ALT  Data  Package  submission  is  routed  externally  for  review  to 
the  SPM  and  Planning  Yard  and  revised  as  required.  The  SPM  approved  TEMPALT  Data 
Package  is  then  forwarded  to  the  TYCOM  for  review  and  authorization  for  the 
installation.  Upon  receipt  of  TYCOM  authorization,  the  SPAWAR  PMW  initiates 
tasking  to  the  Installation  Agent  (IA)  to  perform  pre-installation  and  installation 
activities. 

Note:  The  SPAWAR  PMW  has  responsibility  for  funding  all  activities  associated 
with  the  TEMPALT  design,  pre-installation,  installation,  operational  and  removal  phases. 
a.  Design  Phase  Timelines 

SPAWAR  04R-3  recommends  a  minimum  of  sixteen  weeks  for 
TEMPALT  Design  Phase  activities  because  adequate  time  is  required  to  orchestrate  the 
numerous  and  iterative  activities  within  SPAWAR  and  externally  to  SPM  and  TYCOM 
organizations  for  their  internal  reviews  and  approval.  Approval  is  typically  granted  via 
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each  organization’s  Change  Control  Board  (CCB)  process.  The  recommended  nominal 
timelines  for  each  milestone  are  detailed  below  in  Figure  11.  The  timeline  shown  is 
slightly  revised  from  the  original  for  omitting  reviews  specific  to  AEGIS  surface 
combatants  that  are  not  applicable  to  Command  Ships,  and  is  revised  from  SPAWAR 
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Figure  11.  Nominal  TEMP  ALT  Activity  Timeline,  Scale  in  Weeks  (From 

SPAWAR,  2004) 


b.  TEMPALT Data  Package  Requirements 

The  TEMPALT  Data  Package  is  prepared  by  the  SPAWAR  PMW  and 
includes  the  following  information  that  is  submitted  to  the  Design  Support  Center 
(SPAWAR  04R-3)  for  review,  approval  and  forwarding  to  the  SPM. 

Complete  content  requirements  for  SPAWAR  developed  TEMPALT  Data 
Packages  are  detailed  in  the  SPAWAR  C4ISR  Afloat  Installation  Design  Toolbox 
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(Nowicki,  2002),  for  alterations  that  do  not  impact  ships  maneuverability,  habitability, 
introduce  safety  issues,  or  have  topside  (antennae)  modifications.  A  summary  of  the 
related  documentation  requirements  is  listed  in  Table  3. 

_ TEMPALT  Data  Package _ 

A  description  of  the  alteration  (Alteration  Brief) _ 

Ship  impact  data 

Physical  Arrangements 

Power  Requirements 

System  Interface  Requirements 

Noise,  Shock  and  Vibration  (NSV)  Analysis 

Heat  Ventilation  and  Air  Conditioning  (HVAC)  Requirements 

Signal  Security  (SIGSEC) 

Test  for  Electromagnetic  Propagation  and  Evaluation  for  Secure  Transmissions 
_ (TEMPEST) _ 

Stress  calculations _ 

Weight  and  Moment  calculations _ 

Installation  Drawings  to  include: 

Arrangement  and  Details  Drawing  (ship/system  specific) 

Block  Diagram  (depicting  each  cable)  (system  specific) 

_ Cable  Wiring  Drawings  (ship  specific) _ 

Integrated  Lifecycle  Support  (ILS)  documentation _ 

Removal  Exit  Plan _ 

Table  3.  SPAWAR  TEMPALT  Data  Package  Requirements  (From  Nowicki,  2002) 

2.  TEMPALT  Pre-Installation  Phase  Activities 
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The  Pre-Installation  Phase  activity  is  performed  by  the  SPA  WAR  PMW  to;  1) 
task  the  Installation  Activity  (IA),  2)  procure  the  installation  equipment,  and  3)  to 
coordinate  the  installation  schedule  and  impacts  to  the  ship  via  in-briefs  to  the 
appropriate  TYCOM  and  Battle  Group  stakeholders.  The  SPAWAR  PMW  is  also 
responsible  for  delivery  of  the  SPM  approved  TEMPALT  Data  Package  and  ILS 
certification  to  the  designated  waterfront  activity,  Regional  Maintenance  and 
Modernization  Control  Office  (RMMCO),  to  obtain  pennission  for  ship  access  and 
support  (Nowicki,  2004). 

3.  TEMPALT  Installation  Phase  Activities 

The  Installation  phase  primarily  involves  the  Installation  Activity  (IA)  and  the 
Installation  Management  Office  (IMO),  with  managerial  oversight  from  the  SPAWAR 
PMW.  The  Installation  Activity  and  IMO  perfonn  the  following  activity  steps 
(SPAWAR,  2004): 

a.  Arrange  for  the  Ship’s  Force  training 

b.  Coordinate  installation  check-in  with  the  RMMCO 

c.  Perform  the  installation 

d.  Verify  the  installation  by  performing  the  Ship  Operational  Verification 
Test  (SOVT) 

e.  Coordinate  the  installation  check-out  with  the  RMMCO 

f.  Update  the  SPAWAR  Integrated  Data  Environment  Repository  (SPIDER) 
database 

g.  Submit  red-lined  documents  for  the  alteration  changes 

h.  The  SPAWAR  PMW  is  responsible  for  the  following  activity  steps: 

i.  Produce  the  SOVT  Plan  and  Procedures 

j.  Monitor  the  installation  and  respond  to  any  technical  questions 

k.  Provide  the  ILS  products 
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1.  Report  installation  completion  to  the  SPAWAR  04R-3  Design  Center 

This  phase  concludes  officially  when  the  Commander  of  the  ship  sends  a  Naval 
Message  to  the  TYCOM  and  SPM  that  the  installation  has  been  completed. 

4.  Post-Installation  Completion  Reporting  Phase 

The  final  phase  of  the  TEMP  ALT  lifecycle  is  a  Completion  Reporting  phase  for 
TEMP  ALT  removal.  This  phase  has  two  primary  steps  for  the  SPAWAR  PMW  (Logg, 
2004): 

a.  Initiate  tasking  to  remove  the  TEMP  ALT  and  return  the  ship  to  the 
original  configuration. 

b.  Report  the  removal  to  the  appropriate  SPAWAR  04R-3  Class  Desk 
Manager  and  SPAWAR  04F  Battle  Force  Manager. 

This  concludes  discussion  of  the  phases  and  activities  associated  with  the  formal 
TEMP  ALT  process.  Although  it  is  a  very  detailed  and  sometimes  tedious,  process,  it  is 
critical  to  ensuring  the  installations  on  board  Navy  ships  do  not  hinder  the  Warfighters’ 
ability  to  carry  out  their  mission.  The  days  of  contractors  coming  on  board  a  ship  and 
loading  a  system  here  and  another  system  there  are  over.  Those  practices  resulted  in 
systems  interfering  with  each  others’  functions,  redundancy  in  hardware,  and  system 
administration  nightmares.  This  formalized  approach  attempts  to  eliminate  those  issues 
and  the  process  works  well  in  achieving  that  goal.  However,  there  are  issues  that  the 
installer  must  be  aware  of  prior  to  installing  a  system  afloat  and  the  installation  of  OED 
on  board  the  LCC-19  provided  an  outstanding  opportunity  to  explore  those  issues.  The 
system  had  never  been  formally  installed  on  board  a  ship  so  the  OED  installation  team 
had  never  worked  through  the  afloat  installation  process.  Their  effort  to  leam  and  follow 
the  process  provided  lessons  learned  to  share  with  future  installers. 
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IV.  USS  BLUE  RIDGE  TEMPORARY  ALTERATION 


A.  ALTERATION  INTRODUCTION 

Now  that  the  requirements  have  been  validated  and  assessed  and  the  engineering 
solution  has  been  reached,  the  next  step  in  the  installation  is  the  documentation  of  a 
temporary  alteration  or  TEMP  ALT.  Previously,  a  thorough  engineering  review  of  the 
requirements  determined  an  alteration  to  the  current  ship’s  architecture  to  introduce  the 
OED  CDS  capabilities  greatly  improves  the  afloat  Coalition  mission  by  supporting 
continuous  access  to  four  simultaneous  enclaves  while  eliminating  network  and  hardware 
reconfiguration  requirements  in  support  of  non-US  (Coalition)  stakeholders.  This  chapter 
illuminates  the  step-by-step  process  of  documenting  and  approving  the  TEMP  ALT  to 
support  the  engineering  decisions.  This  TEMP  ALT  (named  the  OED  SCI  MLS  Force 
Level  Architecture  TEMP  ALT)  provides  a  significant  alteration:  a  large  number  of 
server  processors,  client  workstations  and  interface  equipment  in  the  relatively  small  and 
constrained  SCI  spaces. 

B.  TEMP  ALT  ARCHITECTURE  REQUIREMENTS 

Mr.  Steve  Brenneman  (SPAWARSYSCEN-SD),  the  OED  Chief  Engineer,  and 
Mr.  Eugene  Kwiatkowski  (AMSEC),  Lead  Systems  Architect  for  GCCS-M  afloat 
variants,  collaborated  over  several  email  exchanges  to  develop  the  unique  USS  Blue 
Ridge  TEMP  ALT  architecture  shown  in  Figure  12  (Brenneman  &  Kwiatkowski,  2003). 
This  afloat  architecture  is  supported  by  three  UNIX  servers,  four  UNIX  workstations, 
three  PC  servers,  seven  routers,  a  RAID  array,  network  interfaces  to  four  enclaves  and 
various  serial  data  interfaces. 

The  proposed  architecture’s  hardware  and  interface  requirements  for  system 
devices  1-9  in  the  below  paragraphs  (with  manufacture  and  part  number  in  parenthesis) 
are  described  from  interviews  with  Mr.  Richard  Chavez,  OED  Senior  Systems  Engineer 
(Chavez,  2004). 
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Figure  12.  OED  CDS  Architecture  and  Signal  Flow  (From  Brenneman  & 

Kwiatkowski,  2003) 
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1.  OED  SCI  Server  No.  1  (HP  J6000) 

OED  SCI  Server  No.  1  is  the  primary  server  in  the  architecture  and  is 
characterized  as  follows: 

a.  OED  SCI  Server  No.  1  interfaced  to  external  storage  disks  (DS2100) 
and  to  four  distinct  intelligence  networks  at  different  security  domains. 
The  server  supports  track  correlation,  communications  management 
(provides  for  management  of  all  the  communications  interfaces), 
databases,  message  archive,  and  other  functions  that  the  OED 
operators  will  utilize. 

b.  The  GENSER  serial  signals  TRE,  GENSER  GCCS-M,  OTCIXS,  RCV 
GCCS-M  RM  are  supplied  to  the  GENSER  Communications 
Multiplexer  which  provides  the  path  for  message  traffic  to  the  OED 
SCI  Server  No.  1  and  to  the  OED  Coalition  Server. 

c.  GCCS-M  serial  SIPRNET  connectivity  is  provided  by  the  Radiant 
Mercury  (RM)  track  sanitizer  (SUN  Ultra  5  Workstation). 

d.  The  SCI  Gale  and  SCI  GCCS-M  serial  interface  with  Radiant  Mercury 
(RM)  allows  for  sanitized  tracks  to  be  processed  via  a  single  OED 
Coalition  Server  to  any/all  of  the  Coalition  users  and  to  the  SCI 
components  (JWICS,  BISON,  and  STONEGHOST)  via  SCI  OED 
Server  No.  1. 

e.  The  program  office  is  pursuing  the  accreditation  of  serial  SIPRNET 
network  connectivity  while  connected  to  STONEGHOST  and  JWICS. 
Approval  is  estimated  for  February  2005  (Fish,  R.,  personal 
communication,  August  19,  2004). 

2.  OED  SCI  Server  No.  2  (Back  Up  Server) 

OED  SCI  Server  No.  2  (Back  Up  Server)  provides  redundancy  for  OED  SCI 
Server  No.  1  (Primary  Server)  and  is  only  used  for  emergency  purposes.  During  normal 
operations  the  backup  server  is  turned  off  as  a  ready  spare.  Network  connections,  serial 
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interfaces  and  the  external  disk  storage  system  are  manually  relocated  to  the  backup 
server  if  a  failure  should  occur  to  the  primary  server.  The  backup  unit  is  then  brought  on¬ 
line  to  replace  the  primary. 

a.  Both  servers  are  interfaced  to  the  SCI  Network  Switch  at  100Mbps. 
Three  additional  external  network  connections  to  STONEGHOST, 
BISON  and  JWICS  routers  No.  5,  6  and  7  are  supported  at  100Mbps. 

3.  Disk  Storage  System  (DS2100) 

The  DS2100  is  a  rack  mounted  disk  storage  system  that  provides  three  additional 
73  GB  hard  drives  for  data  storage  and  backups.  This  system  was  used  instead  of  a 
typical  OED  ashore  system’s  larger  RAID  device  due  to  shelf  space  constraints  for  the 
technically  refreshed  GCCS-M  equipment  racks. 

4.  OED  Coalition  Server  (HP  J6000) 

A  future  OED  Coalition  Server  will  be  interfaced  to  routers  No.  1  thru  No.  4. 
Those  routers  then  interface  to  separate  Coalition  WANs  (COWANs)  for  COWAN  A 
(AUSCANUKUS),  COWAN  C,  COWAN  J  (JMSDF)  and  COWAN  K  (Korea)  provided 
by  an  external  SPA  WAR  program  (CENTRIXS  Block  2)  alteration. 

The  Coalition  Server  and  the  interfaces  to  the  various  COWANs  were  not 
activated  on  USS  Blue  Ridge  because  each  interface  because  of  concerns  raised  by  the 
Type  Commander;  Commander,  Pacific  Fleet  (CPF)  (Stevenson,  R.,  personal 

communication,  June  30,  2003);  that  accrediting  these  interfaces  could  jeopardize  the 
CENTRIXS  Block  2  accreditation.  Although  it  was  later  determined  that  the 

accreditation  volumes  for  each  system  were  independent,  the  network  connections  from 
CENTRIXS  Block  2  were  never  interfaced  with  OED  (Brenneman,  S.,  personal 
communication,  July  18,  2003). 

5.  SCI  PC  Servers  (Vision  V133-1 126) 

The  PC  servers  run  MetaFrame  Proxy  and  PC  client  applications.  BISON, 
STONEGHOST  and  JWICS  PC  servers  are  shown  connected  to  independent  routers  No. 
5,  6  and  7  and  to  the  OED  SCI  Server  No.  1  which  provides  crossover  connectivity 
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between  the  systems  OED  Coalition  units  and  SCI  clients.  PC  servers  rely  on  existing 
SCI  LAN  infrastructure  for  mail  servers,  DNS  servers,  etc. 

The  STONEGHOST  and  JWICS  connections  are  accredited,  but  the  BISON  PC 
Server  will  remain  inactivated  until  it  gets  accredited  (Fish,  R.,  personal  communication, 
August  19,  2004). 

6.  System  Management  Consoles  (SAIC  Neptune) 

Two  rack-mounted  work  centers,  one  per  equipment  rack,  provide  for  system 
administration  for  up  to  eight  UNIX  and  PC  servers.  Each  work  center  provides  the 
ability  to  utilize  a  KVM  switch  to  a  single  keyboard,  trackball  and  display  to  multiple 
servers,  thus  minimizing  hardware  peripheral  duplication. 

7.  UNIX  Workstations  (HP  J6000) 

There  are  four  UNIX  client  workstations  that  run  an  ICA  client  to  allow  the  user 
to  display  and  run  PC  applications  running  in  different  security  domains  from  a  single 
workstation  along  with  the  local  HP  UNIX  applications.  The  workstations  provide  for 
message  parsing,  correlation,  message  archive  search  functions,  and  similar  services  that 
are  run  on  the  OED  SCI  Server.  All  of  the  clients  are  used  for  situational  awareness 
display,  SCI/Special  Access  Program  (SAP,  a  more  restrictive  security  domain  inside  the 
SCI  security  domain)  track  management,  message  archive  searching,  message 
queuing/profding,  intelligence  product  generation  (mostly  intelligence  messages),  and 
other  client  functions.  All  of  the  clients  have  an  identical  OED  software  load  on  them 
and  are  named  differently  for  the  type  of  operator  that  was  using  that  client. 

The  different  UNIX  workstation  positions  are  referenced  as;  Collections  Client 
Workstation,  IWO  Client  Workstation,  AIWO  Client  Workstation  and  Targeting  Client 
Workstation. 

Each  rack-mounted  client’s  video,  keyboard  and  trackball  interfaces  are  extended 
(via  CAT-5  transmitters  and  receivers  to  distant  desktop  locations  to  provide  for  a  smaller 
desktop  footprint.  Therefore,  each  operator  seat  is  comprised  of  a  keyboard,  trackball 
and  18”  (NEC  1850X)  flat  panel  display.  The  UNIX  workstations  are  interfaced  to  the 
SCI  Network  Switch  at  100Mbps. 
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8.  Radiant  Mercury  Sanitizer 

Radiant  Mercury  (RM)  provides  sanitization  for  downgrading  tracks  to  the 
multiple  OED  serial  communications  interfaces.  The  OED  implementation  of  RM  is  in 
addition  to  a  GCCS-M  RM  installation  that  sanitizes  tracks  and  imagery  between  SCI  and 
GENSER  communications  processors.  The  OED  RM  is  configured  with  a  rule  set 
specifically  for  the  OED  multi-level  requirements  (Fish,  R.,  personal  communication, 
August  30,  2004). 

9.  SCI  Network  Switch  (ALCATEL  Omni  Switch  4024) 

The  additional  SCI  network  interfaces  were  provided  by  a  24  port  workgroup 
switch.  Media  converters  were  installed  to  allow  connectivity  to  the  appropriate  routers 
and  switches  to  achieve  TEMPEST  requirements  and  security  accreditation  requirements. 

C.  TEMP  ALT  SOLUTION 

This  section  will  discuss  the  OED  system  requirements  and  the  associated 
challenges  for  such  a  large  implementation  in  a  space  constrained  shipboard  environment. 

1.  Shipboard  Equipment  Racks 

The  purpose  of  an  equipment  rack  is  to  consolidate  equipment  vertically  in 
constrained  shipboard  spaces  while  protecting  equipment  in  its  payload  area  from  harsh 
naval  environments.  The  payload  area  for  an  equipment  rack  is  characterized  in  terms  of 
available  rack  units  (RUs),  where  a  rack  unit  measures  1.75”  vertically. 

Equipment  racks  are  secured  on  board  ships  with  a  steel  foundation  mount 
assemblies  and  bulkhead  mount  assemblies.  These  assemblies  incorporate  steel  rope 
coils  to  isolate  the  cabinet  and  its  payload  from  the  effects  of  vibration  and  shock,  typical 
in  naval  environments.  The  cabinets  also  include  fan  assemblies  that  force  cool  filtered 
air  into  the  bottom  and  throughout  the  payload  area  and  to  exhaust  heat  that  is  radiated 
from  the  payload  contents.  The  filters  cleanse  the  air  of  harmful  particles  such  as  dust, 
sand,  lent  and  dander. 

Equipment  racks  also  provide  panels  for  external  interfaces  for  input  power, 
communications  data,  and  the  network.  Power  anomalies  are  a  fact  of  life  on  a  Navy 
vessels  (even  on  a  nuclear  carrier)  and  electrical  equipment  are  subject  to  spikes,  surges 
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and  outages  as  electrical  grids  are  adjusted.  A  Universal  Power  Supply  (UPS)  assembly 
interfaces  to  a  20  AMP  service  feed  to  provide  protection  for  all  cabinet  subassemblies. 
The  UPS  is  in  turn  interfaced  to  a  Power  Distribution  Assembly  (PDA)  that  provides 
power  distribution  to  eight  circuits  and  allows  for  selective  shutdown  of  cabinet’s 
subassemblies. 

The  installation  of  an  equipment  rack  is  a  major  undertaking  for  a  SHIP  ALT  or  a 
TEMP  ALT.  Passageways  are  not  adequate  to  land  bulky  cabinets  into  an  equipment 
room  or  operator  space,  so  an  alteration  installation  team  (AIT)  will  have  to  orchestrate 
the  more  complicated  tasks  associated  with  opening  bulkheads  and  using  hoisting  cranes 
to  land  a  rack  onto  a  ship.  Additionally,  the  installation  activity  costs  increase  for  the 
supporting  shipyard  riggers  and  welders. 

The  OED  program  is  a  member  of  the  GCCS-M  family  of  systems.  To  conserve 
installation  costs  and  time,  an  SSC-SD  ship  check  team  in  coordination  with  the  ship’s 
SCI  enclave  stakeholders,  detennined  that  there  was  an  opportunity  to  technically  refresh 
two  underutilized  55”  GCCS-M  equipment  racks.  A  drawing  for  the  legacy  racks  is 
shown  in  Figure  13  (Brenneman  &  Kwiatkowski,  2003).  Development  of  the  USS  Blue 
Ridge  OED  TEMPALT  data  package  proceeded  to  document  the  landing  of  core  OED 
system  components  in  the  Fleet  Intelligence  Center  (FIC)  space,  third  deck,  frame  3-67- 
0-Q. 
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Figure  13.  Legacy  GCCS-M  Equipment  Racks  (From  Brenneman  & 

Kwiatkowski,  2003) 

Each  GCCS-M  equipment  rack  contained  two  older  technology  HP  processors 
(circa  1995)  that  were  mounted  vertically,  consuming  the  majority  of  the  rack’s  payload 
area.  The  racks  also  had  dated  UPS  assemblies,  PDAs  and  suspect  fan  assemblies.  The 
refreshment  plan  was  to  overhaul  each  rack  completely  and  to  refresh  the  power  and  fan 
subsystems  with  smaller  and  advanced  solutions  that  contribute  to  increased  rack  units  in 
the  payload  area.  The  large  processors,  PDAs  and  older  UPS  assemblies  would  therefore 
be  removed  leaving  a  bare  cabinet  assembly  on  coils  to  support  the  TEMP  ALT  upgrades. 

The  OED  SCI  MSL  Architecture  Force  Level  suite  of  equipment  consists  of  the 
two  technically  refreshed  racks  depicted  in  Figure  14  (Brenneman  &  Kwiatkowski, 
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2003),  referenced  for  the  remainder  of  this  chapter  as  Rack  No.  1  on  the  left  side  and 
Rack  No.  2  on  the  right. 


Figure  14.  TEMPALT  Adjusted  Racks  (From  Brenneman  &  Kwiatkowski,  2003) 

The  following  components  were  added  to  Rack  No.  1  (in  top-down  order): 

•  1RU  PDA,  8  circuit  (SAIC  1 12-32500) 

•  24  Port  Workgroup  Switch  (OS  4024) 

•  Media  Converter,  8  port  (MILAN  9100X) 

•  Sun  Rave  Radiant  Mercury  (RM2DIA-AX1 105) 

•  SCI  Server  No.  1  (HP  J6000) 

•  SCI  Server  No.2  (HP  J6000) 

•  Neptune  Workstation  Center  (SAIC  136-32000) 

•  SCSI  Expansion  Chassis  (SAIC  168-32000) 

•  Disk  Storage  System  (DS2 100) 

•  Router  (CISCO  2621) 
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•  Coalition  Server  (HP  J6000) 

•  IWO  Client  Workstation  (HP  J6000) 

•  2.4  KVA  UPS  (Clary  UPS1-2.4K-1G-SRNDTI-J3) 

The  following  components  were  added  to  Rack  No.  2  (in  top-down  order): 

•  1RU  PDA,  8  circuit  (SAIC  1 12-32500) 

•  Router  (CISCO  2621),  quantity  2 

•  Stoneghost  PC  Server  (Vision  VI 33- 1126) 

•  Bison  PC  Server  (Vision  V133-1 126) 

•  JWICS  PC  Server  (Vision  V133-1 126) 

•  AIWO  Client  Workstation  (HP  J6000) 

•  Targeting  Client  Workstation  (HP  J6000) 

•  Neptune  Workstation  Center  (SAIC  136-32000) 

•  Router  (CISCO  2621),  quantity  4 

•  Media  Converter,  8  port  (MILAN  9100X) 

•  Collections  Client  Workstation  (HP  J6000) 

•  2.4  KVA  UPS  (Clary  UPS1-2.4K-1G-SRNDTI-J3) 

The  peripheral  components  for  the  data  package  included  the  mounting  of  seven 
PC  clients  along  and  four  remote  operator  positions  that  include  an  18”  flat  panel  display, 
keyboard  and  trackball  over  CAT-5  extenders  from  the  racked  Client  Workstations. 

2.  Milestones  during  TEMP  ALT  Development  and  Installation 

This  section  highlights  milestones  or  products  that  were  delivered  for  the  design, 
pre-installation,  installation  and  completion  phases  associated  with  the  OED  SCI  MLS 
Architecture  TEMPALT  on  USS  Blue  Ridge  (LCC-19).  The  key  activities  for  each  phase 
and  the  responsible  stakeholder  for  the  TEMPALT  are  listed  in  Table  3. 


Activity 

Phase 

Primary 

Stakeholders 

Schedule  Installation,  Select  Ship(s)  and 
Verify  Availability 

Design 

PMW-157, 

SPA  WAR  04F 

Identify  and  Fund  the  Installation  Team 

Design 

PMW-157 

Prepare  TCCP  and  POA&M 

Design 

SPAWARSYSCEN 

24221 
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Produce  Temporary  Justification  Cost  Form 
(TJCF) 

Design 

SPAWARSYSCEN 
24221,  SPAWAR 
04R-3 

Initiate  Integrated  Logistics  Support  (ILS) 
Product  Development 

Design 

PMW-157L 

Produce  TEMPALT  Data  Package 

Design 

SPAWARSYSCEN 

24221 

Complete  TEMAPALT  Data  Package  Review 

Design 

SPM,  Planning 

Yard,  TYCOM 

Pre-Installation  Activity 

Pre-Installation 

SPAWARSYSCEN, 
Code  24224 

Installation  Activity 

Installation 

SPAWARSYSCEN, 
Code  24224 

Post-Installation  Activity 

Post- 

Installation 

Performing  Activity 
(TBD) 

Table  4.  OED  TEMP  ALT  Process  Activities 


The  following  notes  are  specific  to  the  OED  SCI  MLS  Architecture  TEMPALT 
(White,  2004): 

1.  The  NAVSEA  Ships  Program  Manager  (SPM)  was  Sherrie  Johnson,  PMS 
470  (Command  Ships).  Shortly  after  the  TEMPALT  approval  PMS-470 
merged  with  PMS-400  (Surface  Combatants)  to  become  PEO-Ships. 
PEO-Ships  is  the  SPM  for  all  surface  ships  except  for  Carriers  (PEO- 
Carriers)  and  Submarines  (PEO-Submarines). 

2.  The  applicable  TYPE  Commander  (TYCOM)  for  USS  Blue  Ridge  (LCC- 
19)  is  COMNAVSURFPAC.  The  point  of  contact  for  review  and 
authorization  of  the  TEMPALT  was  Many  Panis,  CNSP  N603C. 

3.  The  SPAWAR  04F  Command  Ship  Battle  Force  Manager  (BFM)  during 
the  time  when  the  OED  TEMPALT  was  processed  was  L.T.  Clay 
Glasheen.  Note:  L.T.  Clay  Glasheen  has  since  moved  on  and  has  been 
replaced  with  L.T.  Tanya  Wallace. 

4.  The  SPAWAR  04R-3  point  of  contact  is  Bob  Buckley,  Director, 
SPAWAR  Design  Support  Center,  Head,  C4ISR  Implementation  Design 
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&  Support  Division,  SPAWAR  Fleet  Modernization  Program  Policy 
Coordinator. 

5.  The  Boston  Planning  yard  representative  for  LSD,  LPD,  AGF  and  LCC 
classes  is  Kelly  Bailey,  an  On-Site  Engineer  at  SPAWAR  headquarters. 

6.  The  PMW-157  OED  Program  Manager  is  Christopher  Newcomb. 

7.  The  logistics  lead  for  Integrated  Logistics  Support  (ILS)  certification  is 
Timothy  Green,  PMW-157L. 

8.  TEMP  ALT  design  and  documentation  development  was  lead  by  John 
Falbo,  SPAWAR  Systems  Center  (SPAWARSYSCEN),  San  Diego,  Code 
24221. 

9.  The  lead  perfonner  for  the  pre-installation  and  installation  activities  was 
Mark  Gabriels,  SPAWAR  Systems  Center  (SPAWARSYSCEN),  San 
Diego,  Code  24224. 

3.  Design  Phase  Products  and  Milestones 

This  section  discusses  the  design  phase  products  and  timelines  supporting  the 
development  through  authorization  milestones  specifically  associated  with  the  OED  SCI 
MLS  Architecture  TEMPALT. 

a.  TYCOM  Authorization  -  The  OED  SCI  MLS  Architecture  TEMPALT 
on  the  USS  Blue  Ridge  (LCC- 19)  was  considered  after  close 
coordination  between  OED  program  office,  COMPACFLT  and 
COMSEVENTHFLT  (USS  Blue  Ridge)  stakeholders.  The  alteration 
was  requested  by  COMSEVENTHFLT  via  Navy  Message  (DTG: 
040415ZAPRIL  03)  and  endorsed  by  COMPACFLT  (DTG:  14234 1Z 
MAY  03).  Note:  The  USS  Blue  Ridge  was  listed  in  a  CNO  Ships 
Restricted  Availability  (SRA)  for  the  period  of  29  May  through  30 
July,  2003. 

b.  TCCP,  POAM  and  TJCF  -  PMW-157  developed  a  TEMPALT  Change 
Control  Proposal  (TCCP)  that  included  a  Plan  of  Action  and 
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Milestones  (POA&M)  after  receipt  of  the  COMSEVENTHFLT 
alteration  request.  This  infonnation  is  later  included  as  supporting 
attachments  to  the  more  detailed  alteration  disclosure  known  as  the 
TEMP  ALT  data  package.  The  TEMP  ALT  Justification/Cost  Form 
(TJCF)  was  developed  by  SPAWAR  04R-3  from  information  provided 
in  the  TCCP.  The  draft  TJCF  was  reviewed  and  signed  by  SPAWAR 
04R-3  and  PMW-157  and  then  submitted  to  the  SPM  for  review  and 
signoff  approximately  14  May,  2003.  The  TEMP  ALT  was  referenced 
internally  to  corporate  SPAWAR  as  “TA134”. 

c.  Ship  Check  -  SPAWAR  PMW-157  considered  TEMP  ALT 
accomplishment  to  be  within  the  capability  of  an  Alteration 
Installation  Team  (AIT).  The  San  Diego  based  team  was  selected  due 
to  their  familiarity  with  earlier  GENSER  and  SCI  GCCS-M 
installations  supporting  the  USS  Blue  Ridge  (LCC-19).  The  ship 
check  was  consolidated  with  a  SCI  GCCS-M  software  upgrade  for  the 
time  period  of  03/01/03  through  03/05/03. 

d.  TEMPALT  Data  Package  -  The  OED  SCI  MLS  Architecture 
TEMP  ALT  Data  Package  and  supporting  attachments  for  alteration 
drawings  and  ILS  certification  was  submitted  to  the  SPM  and  PY  on 
05  June,  2003  (Reference  Appendix  B).  These  attachments  are 
included  as  additional  appendices  in  this  document  for  review 
purposes. 

i.  TEMPALT  Arrangement  Drawing  (Reference  Appendix  C) 

ii.  TEMPALT  Cable  Block  Diagram  (Reference  Appendix  D) 

iii.  TEMPALT  ILS  Certification  (Reference  Appendix  E) 

e.  ILS  Products  -  ILS  certification  submission  to  the  SPM  was  provided 
on  10  June,  2003. 
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f.  The  SPM  assigns  a  NAVSEA  TEMP  ALT  number  and  inputs  the 
information  into  the  Navy  Data  Environment  -  Navy  Modernization 
(NDE-NM)  database  and  the  OED  SCI  MLS  Architecture  TEMP  ALT 
is  referenced  in  the  database  as  TA1517  on  1 1  June,  2003. 

g.  TYCOM  (COMNAVSURFPAC)  authorization  of  TEMP  ALT  Data 
Package  (Reference:  DTG  1 1 1812ZJUN03) 

4.  Pre-Installation  Phase  products  and  Milestones 

The  Pre-Installation  Phase  activity  provides  the  coordination  and  preparation  for 
the  alteration  installation.  This  activity  consists  of  the  following  steps  to  be  perfonned  by 
SPA  WAR  PMW-157: 

a.  Complete  procurement  activities  and  prepare  shipments  to  support  the 
alteration  requirements  prior  to  the  estimated  start  date  of  09  June, 
2003. 

b.  Coordinate  the  alteration  with  the  SPM,  TYCOM,  Fleet  Stakeholders 
with  in-briefs  scheduled  for  30  June,  2003.  Normally  this  would  be 
done  ahead  of  the  install  window,  but  since  this  alteration  was  in  Japan 
the  in-brief  was  accomplished  the  first  day  of  the  three  week 
installation  window  (30  June  through  21  July,  2003). 

c.  Obtain  SPM  approved  copies  of  the  TEMPALT  Data  Package  with 
ILS  certification  for  RMMCO  check-in  on  30  June,  2003. 

5.  Installation  Phase  Products  and  Milestones 

The  Installation  Activity  involves  primarily  the  Installation  Activity  and  the 
Installation  Management  Office  (IMO),  with  monitoring  and  tasking  support  from 
SPA  WAR  PMW-157. 

a.  The  Installation  Activity  and  IMO  perform  the  following  activity 
steps: 

b.  Coordinate  installation  check-in  with  RMMCO  on  01  July,  2003. 


58 


c.  Perform  installation  and  on-the-job  training  from  02  July  through  20 
July,  2003. 

d.  Verify  the  new  system  installation  by  completing  the  Ship  Operational 
Verification  Test  (SOVT)  on  20  July,  2003. 

e.  Coordinate  the  installation  check-out  with  RMMCO  on  20  July,  2003. 

f.  Update  the  SPAWAR  Integrated  Data  Environment  Repository 
(SPIDER)  database  (approximately  2 1  July,  2003). 

g.  Submit  red-lined  drawings  to  the  Planning  Yard  for  the  alteration 
changes  on  28  July,  2003. 

SPAWAR  PMW-157,  the  sponsoring  activity,  was  responsible  for  the  following 
activity  steps: 

a.  Produce  the  SOVT  Plan  and  Procedures  prior  to  installation  start. 

b.  Monitor  the  installation  and  respond  to  any  technical  questions. 

c.  Report  Installation  completion  to  the  SPAWAR  04R-3  Design  Center. 
Note:  The  Commander  of  the  Ship  will  send  a  Naval  Message  to  the 
TYCOM  and  SPM  that  the  Installation  has  been  completed. 

6.  Completion  Reporting  Phase  Products  and  Milestones 

A  post  completion  decision  to  retain  or  remove  the  TEMPALT  needs  to  be 
addressed  before  the  alteration  turns  a  year  old,  reference  Figure  15.  The  TYCOM  can 
consider  options  to: 

a.  Restore  the  ship  to  its  original  configuration 

b.  Extend  the  TEMPALT  for  specific  tenn  (typically  a  year) 
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c.  Approve  the  alteration  as  a  SHIP  ALT 


Figure  15.  Remove/Extend/Convert  TEMPALT 

The  present  status  of  the  OED  SCI  MLS  Architecture  TEMPALT  on  USS  Blue 
Ridge  is  that  it  remains  on  board,  while  the  ship  is  in  the  ship  yard  undergoing  repairs, 
even  though  it  should  have  been  removed  in  July,  2004  per  the  removal  plan.  The  OED 
program  office  is  currently  in  collaboration  with  NETWARCOM  requesting  funding  to 
support  a  second  year’s  extension. 

D.  SUMMARY 

This  chapter  overviewed  the  OED  system  requirements  in  terms  of  signal  flow 
and  the  associated  hardware  components  interfacing  to  multiple  network  domains  and 
external  systems.  Space  for  equipment  is  very  limited  in  ship  spaces,  and  the  TEMPALT 
authors  coordinated  with  the  fleet  stakeholders  to  accommodate  all  the  server  and 

network  components  as  a  technical  refreshment  of  two  55”  legacy  SPAWAR  PMW-157 
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program  equipment  racks.  Operator  positions  were  also  technically  refreshed  with 
rugged  UNIX  and  PC  workstations  with  flat  panel  displays. 

Many  lessons  were  learned  by  OED  representatives  during  the  process  detailed 
above.  These  observations  will  be  summarized  in  Chapter  5  with  a  checklist  to  aid  the 
installation  teams  of  the  future.  In  addition  to  Chapter  5’s  valuable  information,  the 
documentation  developed  by  the  OED  program  office  with  the  assistance  from  the 
Installation  Group  (SPAWAR  04R-3)  during  this  process  have  been  included  in  the 
appendices  to  this  paper. 
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V.  LESSONS  LEARNED 


A.  SHIPBOARD  INSTALLATION  OF  COTS  EQUIPMENT 

The  previous  three  chapters  provided  a  narrative  of  the  afloat  installation  process 
by  describing  the  requirements  process,  the  engineering  analysis  and  solution  for  the 
requirements,  and  the  installation  policies  and  procedures  required  to  field  the 
engineering  solution  afloat.  The  earlier  chapters  not  only  described  the  process  but 
provided  in-depth  insight  into  an  afloat  installation  by  identifying  lessons  learned  and 
best  practices  found  by  the  OED  installation  team.  These  best  practices  and  lessons 
learned  will  be  the  focus  of  this  chapter. 

The  Navy  has  introduced  efficiency  and  cost  savings  with  the  use  of  COTS 
equipment  afloat.  However,  there  are  critical  considerations  to  take  into  account  when 
using  COTS  as  the  OED  installation  team  discovered.  The  shipboard  implementation  of 
each  COTS  component  required  that  the  OED  program  office  procure  specially  designed 
kits  for  the  UNIX  and  PC  servers  to  technically  refresh  the  legacy  GCCS-M  equipment 
racks.  The  kits  included  a  hinged  face  plate,  heavy  duty  slide  rails  and  a  cable  harnesses 
tie  wrapped  to  a  swing  arm  that  provided  support  for  each  processor’s  power  and 
communications  requirements.  Additional  rack  assemblies  included  rack  mounted  KVM 
displays,  UPS  assemblies,  fan  assemblies,  power  distribution  assemblies  and  a  prototype 
mounting  shelf  for  the  numerous  routers  and  related  rear  I/O  panel  network  interface 
requirements. 

Client  positions  provide  analysis  tools  and  decision  aid  support  and  are  designed 
similarly  to  survive  the  harsh  naval  environmental  forces  for  shock  and  vibration.  These 
workstations  were  either  kitted  up  and  collocated  with  the  servers  in  the  equipment  racks 
or  secured  locally  to  an  operator’s  desk.  Each  flat  panel  display  was  enveloped  in  metal 
in  a  metal  frame  which  was  secured  to  the  operator’s  desktop  with  bolts. 

B.  SPA  WAR  PROGRAM  TEMP  ALT  CHECKLIST 

This  research  provides  a  checklist  to  assist  other  SPAWAR  program  offices  in 
understanding  the  numerous  TEMP  ALT  products  and  the  milestones  accomplished  for 
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the  design,  pre-installation,  installation  and  post-installation  phases.  A  SPAWAR 
program  TEMP  ALT  checklist  is  provided  in  Table  4. 


u 

SPAWAR  PROGRAM  TEMP  ALT  CHECKLIST 

l.A.  Initiate  Planning  and  Coordination: 

Ensure  command  support  and  concurrence  with  installation  plan 

Prepare  TCCP  and  draft  POA&M 

Submit  TCCP  and  POA&M  to  SPAWAR  04R-3 

■ 

■ 

SPAWAR  04R-3  Assigns  TEMP  ALT#  and  creates  entry  into  SPIDER 

l.B.  Obtain  Authorization: 

Select  Ship(s)  and  Verify  CNO  Availability 

Submit  Non-Standard  Install  Offer  Message  to  TYCOM.  Submit  to  CINC  for  installs  affecting  BG 
Interoperability. 

Receive  TYCOM  and/or  FLTCOOM  authorization  to  perform  installation 

Identify  and  receive  funding  necessary  for  installation 

1 

Identify  critical  Points-of-Contact  and  introduce  them  to  the  effort 

Shipyard,  SPAWAR  on-site  personnel,  RMMCO,  etc. 

l.C  Develop  Temporary  Justification  Cost  Form  and  ILS  Documentation: 

Prepare  Temporary  Justification  Cost  Form  (TJCF)  with  SPAWAR  04R-3 

Initiate  Integrated  Logistics  Support  (ILS)  Product  Development 

SPAWAR  04R-3  submits  TJCF  to  NAVSEA  Ships  Program  Manager  (SPM) 

1 

Receive  SPM  review  and  approval  for  TJCF 

2.0  Ship  Check: 

Request  authorization  to  perform  ship  check  from  cognizant  TYCOM 

Receive  authorization  to  perform  ship  check  from  cognizant  TYCOM 

Identify  and  fund  the  Installation  Team 

Perform  ship  in-brief  and  ship  check 

Develop  ship  specific  drawings  supporting  the  TEMP  ALT  Data  Package  for  electrical,  mechanical  and 
interface  data 

3.0  TEMP  ALT  Data  Package 

3.A  TEMP  ALT  Data  Package  Development: 

Description  of  the  Alteration  (Alteration  Brief) 

Plan  of  Action  and  Milestones  (POA&M) 

Ship  Impact  Data 

Physical  Arrangements 

Power  Requirements 

System  Interface  Requirements 

Noise,  Shock  and  Vibration  (NSV)  Analysis 

Heat  Ventilation  and  Air  Conditioning  (HVAC)  Requirements 
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Signal  Security  (SIGSEC) 

Test  for  Electromagnetic  Propagation  and  Evaluation  for  Secure  Transmissions  (TEMPEST) 

Stress  Calculations 

Calculated  Weight  and  Moments  Record 

Ship-specific  TEMPALT  Installation  Drawings 

Arrangement  Drawings 

Cable  Block  Diagram 

Cable  Wiring  Drawings  or  Cable  Running  Sheets 

Integrated  Logistics  Support  (ILS)  Certification 

Removal/Exit  plan  established  with  funding  identified 

Identify  accreditation  boundaries  and 

D 

Determine  accreditation  requirements  for  those  boundaries 

3.B  TEMPALT  Data  Package  Approval 

Submit  TEMPALT  Data  Package  for  SPM  Review 

Receive  SPM  approval 

SPM  submits  the  TEMPALT  Data  Package  for  TYCOM  authorization 

Receive  TYCOM  authorization 

Submit  TEMPALT  Data  Package  and  ILS  Certification  to  the  designated  waterfront  activity  or  Regional 
Maintenance  and  Modernization  Control  Office  (RMMCO)  as  appropriate. 

Receive  RMMCO  approval  to  proceed  with  alteration 

p 

II 

4.0  Pre-Ship  Installation  Process 

Coordinate  the  TEMPALT  pre-installation  RMMCO  as  appropriate 

Procure  all  installation  equipment 

Run  initial  lab  tests  on  equipment  upon  receipt 

Pre-stage  all  equipment,  run  equipment  tests  again. 

Task  and  assign  the  Installation  Activity 

i 

Lead  ship  in  brief 

5.0  Installation  Process 

Start  and  complete  the  TEMPALT  installation  requirements 

Provide  training  support 

Perform  certification  testing  to  ensure  completion 

Deliver  ILS  products 

Report  installation  completion  to  SPAWAR  04R-3 

■ 

Installation  Completion  Navy  Message  to  TYCOM/FLTCINC 

■ 

6.0  Post  Ship  Install  Process 

Carry  out  the  removal  exit  plan  to  return  the  ship  to  its  original  configuration 

Completion  Reporting  to  SPAWAR  04R-3,  SPAWAR  04F,  TYCOM  and  FLTCINC 

Table  5.  SPA  WAR  Program  TEMPALT  Checklist  (From  SPA  WAR) 
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C.  RECOMMENDED  VERSUS  ACTUAL  TIMELINES  FOR  TEMPALT 

ACTIVITIES  AND  MILESTONES 

The  TEMPALT  process  is  performed  in  the  context  of  the  NAVSEA  Fleet 
Readiness  Program  (FRP)  timeline  (reference  Figure  11).  The  FRP  timeline  establishes 
the  need  dates  for  the  design  artifacts  required  to  support  an  installation.  Figure  10  shows 
the  first  product  (the  TCCP  and  POA&M)  must  be  delivered  to  SPAWAR  04R-3  twelve 
weeks  prior  to  the  installation  date.  Table  5  tabulates  the  information  from  the  nominal 
timeline  and  matrixes  TEMPALT  products  (gray  rows)  and  activities  (white  rows)  in 
activity  or  milestone  order.  The  timeline  column  is  scaled  in  weeks  prior  to  the 
installation  start  date. 

The  purpose  of  this  section  is  to  compare  recommended  delivery  dates  for 
standard  TEMPALT  products  and  activities  to  the  actual  products  and  activities 
associated  with  the  OED  SCI  MLS  Architecture  TEMPALT  (TA1517).  The  column 


labeled  Nominal  Date  is  a  converted  calendar  date  from  the  installation  target  date  of  09 
June,  2003. 


TEMPALT 

Timeline 

Nominal 

Actual 

Activity  or  Milestone 

(Weeks) 

Date 

Date 

Select  Ship,  Liaison  with  TYCOM  via  04F 

1-16 

03  March 

04  April 

Submit  Non-Standard  Install  Offer  Message 

1-14 

1 7  March 

14  May 

TCCP  and  POA&M  Submitted  to  04-R3 

1-12 

31  March 

08  May 

TJCF  Submitted  to  SPM 

1-12 

31  March 

14  May 

Ship  Check  start 

1-10 

14  April 

03  March 

TEMPALT  Data  Package  Start 

1-10 

14  April 

15  May 

TEMPALT  Data  Package  Submitted  to  04-R3 

1-8 

28  April 

02  June 

Ship  Check  completed 

1-8 

28  April 

07  March 

TEMPALT  Data  Package  Submitted  to  SPM 

1-4 

12  May 

05  June 

ILS  Certification  Submitted  to  SPM 

1-2 

26  May 

10  June 

SPM  Approval 

I 

09  June 

1 1  June 

TYCOM  Authorization 

I 

09  June 

1 1  June 

RMMCO  Approval  of  TEMPALT  Package 

I 

30  June 

Installation  Start 

I 

30  June 

Table  6.  OED  TEMPALT  Timelines  1 

For  Activities  and  Products 
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Two  general  observations  can  be  made  from  Table  5.  First,  the  OED  program 
office  representatives  initiated  activities  and  the  development  of  products  approximately 
four  to  two  weeks  behind  the  recommended  schedule.  A  compressed  development  and 
delivery  schedule  was  accomplished  with  close  teaming  and  coordination  with  both 
Battle  Force  Manager  (SPAWAR  04F)  and  the  Design  Support  Center  (SPAWAR  04R- 
3)  representatives.  The  POA&M  installation  target  of  09  June  was  missed  by  three 
weeks  because  of  additional  activities  required  for  RMMCO  check-in  and  approval  of  the 
TEMP  ALT  Data  Package.  This  ultimately  verifies  the  nominal  schedule,  where  starting 
two  to  four  weeks  late  and  close  attention  of  OED  support  members  yielded  a  three  week 
late  installation  start. 

A  secondary  observation  is  for  external  reviewers  and  their  processes.  SPAWAR 
04R-3  representatives  work  closely  with  external  SPM  and  TYCOM  recommendations 
and  could  request  expedited  review  of  the  various  deliverables.  What  caught  most 
everyone  by  surprise  was  the  addition  process  time  afforded  for  obtaining  the  TYCOM 
approved  TEMP  ALT  Data  Package  and  ILS  Certification  and  checking  these  products  in 
with  RMMCO.  RMMCO  is  the  “gate  keeper”  at  the  waterfront,  and  you  can’t  start 
installation  activities  without  their  concurrence.  The  primary  lesson  learned  is  the 
RMMCO  check-in  and  approval  process  can  take  several  weeks. 

D.  FLEET  INPUTS 

The  one  factor  that  kept  this  process  going  throughout  the  TEMP  ALT  timeline 
listed  in  Table  5  was  the  Fleet’s  inputs.  If  the  USS  Blue  Ridge  or  the  Seventh  Fleet  staffs 
had  not  forcefully  demanded  the  installation  of  OED  on  board  LCC-19,  the  installation 
would  have  been  delayed  to  the  next  availability  (four  to  five  months  later)  or  cancelled 
entirely.  The  OED  Program  Office  collected  the  Warfighters’  concerns  and  requirements 
and  used  these  to  keep  the  process  going  when  it  seemed  to  be  stopped.  As  evidenced  in 
our  actual  versus  recommended  timeline  numbers,  the  OED  installation  team  was  able  to 
push  thru  documentation  at  a  rate  much  faster  than  the  recommended  timeframe.  The 
ability  to  compress  the  time  requirements  was  fueled  entirely  by  the  Fleet’s  insistence 
that  OED  get  installed  in  that  availability. 

E.  ACTUAL  VERSUS  PLANNED  SYSTEM  IMPLEMENTATION 
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Although  the  original  architecture  was  developed  and  proposed  by  a  team  of  CDS 
and  systems  experts  (the  SPAWAR  CDS  IPT),  the  process  of  evolving  from  the  best 
engineering  solution  to  the  Warfighters’  requirements  to  the  installed  solution  set  is  a 
tortuous  road.  The  installation  team  must  be  ready  to  address  sudden  implementation 
changes  (which  is  ironic  when  the  actual  process  is  very  rigid)  due  numerous  issues. 

1.  Chain  of  Command  Issues 

The  proposed  architecture  relied  heavily  on  OED  to  be  the  cornerstone  of  the 
Coalition  architecture.  The  SPAWAR  CDS  IPT  recognized  the  need  to  address  all  three 
states  of  data  (at  rest/storage,  in  transit,  and  in  process)  in  the  Coalition  architecture  in 
order  to  provide  the  Warfighter  with  the  best  solution  to  his  Coalition  requirements.  For 
example,  MLTC  is  a  very  good  tool  for  eliminating  multiple  monitors/PCs  on  the 
Warfighter’s  desk  but  the  Warfighter  is  forced  to  correlate  the  four  or  five  windows  on 
his  MLTC  monitor  if  the  data  provided  is  of  any  use  to  him.  MLTC  with  an  OED  now 
provides  a  means  to  view  different  security  domains  with  the  correlation  process 
occurring  in  the  background  on  the  OED  server.  Another  example  is  CENTRIXS. 
Coalition  networks  are  a  very  good  means  of  transiting  data  between  Coalition  partners 
and  US  Warfighters.  However,  the  network  ends  in  a  server  with  no  means  to  transfer 
data  between  the  networks  and  no  value  added  by  bringing  in  track  data  from  other 
sources  since  the  data  can’t  be  correlated  with  the  larger  set  of  data  for  that  track.  With 
CENTRIXS  and  OED,  the  data  can  be  labeled  with  its  origin  (thus  honoring  bilateral 
agreements),  utilized  by  the  correlators  to  get  the  best  picture  (OED  performs  correlation 
on  the  entire  set  of  data  from  SCI  to  Coalition  while  protecting  the  security  levels  of  all 
the  data),  and  the  best  COP  can  then  be  disseminated  to  everyone  in  the  battle  space  with 
the  correct  associated  data  according  to  their  clearances  and  bilateral  agreements. 

However,  due  to  personalities,  risk  aversion,  and  other  issues,  the  proposed 
architecture  was  not  carried  out  in  the  installation  of  OED.  Many  of  the  communications 
channels  were  not  interfaced  and  the  GENSER  Coalition  OED  was  never  implemented. 
It  is  critical  that  the  Program  Office  ensure  chain  of  command  approval  and  backing  prior 
to  starting  the  installation  process.  Again,  the  Fleet’s  support  in  this  matter  will  benefit 
the  program’s  cause. 
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2.  Security  Accreditation  Issues 

Accreditation  issues  are  always,  always  going  to  be  critical  to  a  successful 
installation.  The  OED  program  has  been  accredited  over  48  times  so  the  general  feeling 
of  the  installation  team  was  accreditation  was  the  easy  piece  of  the  problem. 
Unfortunately,  accreditation  is  never  easy  and  the  OED  Program  Office  should  have 
brought  the  accreditors  into  the  process  early.  The  actual  OED  system  accreditation  was 
rather  straightforward  (as  expected).  The  accreditation  issues  arose  when  the  accreditors 
looked  at  the  OED  interfaces  with  other  programs.  Although  OED  interfaces  with  many 
different  networks,  communication  lines,  and  systems  in  its  ashore  installation,  many 
personnel  involved  in  the  installation  process  for  the  entire  Coalition  architecture  decided 
the  risk  of  accrediting  OED  interfaces  with  GCCS-M  (two-way)  and  CENTRIXS/MLTC 
architecture  was  too  great.  As  it  turned  out,  OED  is  accredited  at  all  of  its  shore  sites  to 
interface  with  GCCS  (either  GCCS-M  or  the  Joint  GCCS).  The  other  issue  was  the  risk 
of  CENTRIXS/MLTC  accreditation  failing  due  to  the  OED/CENTRIX  accreditation  if 
that  should  fail.  After  discussing  the  issue  with  all  the  accreditors  involved,  it  was  agreed 
that  the  accreditation  boundaries  for  OED  and  CENTRIX/MLTC  made  their 
accreditations  entirely  independent  of  each  other  so  if  the  interface  accreditation  failed, 
neither  system’s  accreditation  would  be  effected  (Thomas,  G.,  personal  communication, 
June  30,  2003).  However,  the  complete  accreditation  was  never  pursued. 

3.  Funding 

Funding  is  always  an  issue  that  must  be  addressed  early  on  and  often  throughout 
the  process.  The  OED  installation  was  so  strongly  supported  by  the  Fleet  up  and  down 
the  chain  of  command  that  the  installation  was  started  without  the  funding  in  hand  at  the 
Program  Office.  Although  it  was  in  the  “do  what’s  best  for  the  Fleet”  spirit  of  the 
Program  Office,  the  funding  never  came  through  and  the  program  suffers  to  this  day  from 
that.  Always  ensure  the  funding  is  in  place  and  the  correct  amount  of  funding  in  each 
acquisition  funding  type  (for  example,  procurement,  maintenance,  operating,  etc.) 
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VI.  CONCLUSION  AND  RECOMMENDATIONS 


The  afloat  installation  process  is  a  very  complex  and  lengthy  process  to  follow  but 
a  very  necessary  process  nonetheless.  It  is  necessary  due  to  the  mission  criticality  of  the 
IT  equipment  and  software  on  board  a  US  Naval  warship.  The  days  of  fighting  with  iron 
canon  balls  and  targeting  by  “eyeing  it”  are  long  gone  and  the  slightest  perturbation  in  the 
Warfighter’s  information  systems  architecture  could  affect  the  command  and  control 
mission,  the  targeting  mission,  the  strike  mission,  and  the  force  protection  (self-defense) 
mission,  to  name  a  few.  It  is  far  too  risky  to  simply  install  hardware  and  software  on 
board  a  ship  without  rigid  processes  and  tried  practices. 

The  OED  installation  afloat  provided  a  “clean  slate”  to  learn  the  up’s  and  down’s 
of  a  rigid  installation  process.  The  team  was  new  to  afloat  installations,  the  system  had 
never  been  fully  installed  on  board  a  ship,  and  the  program  office,  along  with  other 
SPAWAR  partners,  worked  through  many  issues  and  obstacles  to  achieve  a  successful 
installation.  Is  this  the  last  installation  afloat  for  any  SPAWAR  system?  Definitely  not, 
so  the  authors  of  this  paper  were  determined  to  share  the  lessons  learned  of  this 
experience  so  future  installations  can  go  more  smoothly.  It  is  better  to  benefit  from 
lessons  learned  than  to  bog  down  on  lessons  re-leamed  the  hard  way. 

The  critical  components  of  a  successful  installation  are  time,  budget,  and 
command  support.  With  sufficient  time,  funding  and  support,  any  installation  can  be 
accomplished.  In  the  OED  installation,  time  was  an  issue  because  the  installation  started 
much  later  than  it  should  have.  Funding  was  an  issue,  not  so  much  during  the  installation 
process  but,  more  so,  now  during  the  life  cycle  maintenance  of  the  system  (which  is  part 
of  the  installation  process,  as  is  the  disposal/removal  step).  Since  OED  is  a  woefully 
under  funded  program,  funding  problems  arose  during  the  installation,  too,  but  those 
were  not  due  to  the  installation  process  per  se.  Lastly,  command  support  issues  arose 
throughout  the  installation  process.  Most  of  those  were  addressed  by  the  strong  teaming 
of  the  OED  installation  team,  the  program  office,  the  SPAWAR  installation  experts 
(Code  04),  and  the  on-site  SPAWAR  detachment  personnel.  Of  course,  a  lot  of  credit 
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goes  to  the  Fleet  personnel  involved  because  the  pressure  they  applied  to  resolving  the 
issues  definitely  helped  the  team  work  them  out  in  a  timely  fashion.  However,  some 
command  support  issues  did  not  get  worked  out  and  the  proposed  OED  installation  came 
up  short  of  everyone’s  expectations  in  regards  to  communications  channels  and 
SCI/GENSER  services.  Some  of  these  shortfalls  were  based  on  concerns  for  the 
Warfighter’s  ability  to  utilize  the  systems  and  tools  already  on  board  and  the  risk  (real  or 
perceived)  of  setting  up  certain  interfaces  to  those  existing  systems  and  tools. 

Overall,  the  OED  installation  was  a  success  and,  via  interviews  with  the  team, 
researching  the  installation  effort,  and  personal  experience,  the  authors  were  able  to 
dissect  that  success  to  document  lessons  learned  and  a  comprehensive  checklist  for  future 
installers  to  follow,  modify,  and  add  new  lessons  learned.  As  the  installation  policies  and 
procedures  provide  the  basic  foundation  for  every  installation,  the  comprehensive 
checklist  provides  the  future  installer  with  a  tool  to  avoid  pitfalls,  identify  issues,  and 
successfully  complete  an  installation  in  a  timely  manner.  Of  course,  every  installation  is 
unique  and  this  thesis  provides  the  future  installer  with  the  insight  and  forethought  to 
meet  those  unique  concerns  and  problems  early  and  resolve  them  correctly.  It  is  the 
mission  of  every  PEO  and  SPAWAR  employee  to  provide  the  Warfighters  with  the  tools 
they  need  to  successfully  carry  out  their  missions.  Every  effort  should  be  made  to 
efficiently  carry  out  the  PEO/SPAWAR  mission  and  this  thesis,  with  its  lessons  learned, 
best  practices,  and  comprehensive  installation  checklist,  is  a  step  forwards  in  improving 
the  installation  process. 
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APPENDIX  A:  NAVSEA  FLEET  MODERNIZATION  PROCESS, 
VOL  1,  SECTION  9,  SUBSECTION  9-10  TEMPORARY 
ALTERATIONS  (TEMPALTS) 


9-10. 1  Scope 

This  subsection  outlines  the  policy,  process  and  responsibilities  for  development  and 
approval  of  TEMPALTs  proposed  for  accomplishment  on  operational  Fleet  ships. 


9-10.2  Exemptions 

This  subsection  does  not  apply  to  the  following: 

•  Submarines  -  TEMPALTs  proposed  for  accomplishment  on  submarines  or  submersibles  are 
covered  by  reference  S9(z). 

•  Availability  Testing  -  TEMPALTs  performed  as  part  of  dry-dock  or  dockside  testing  during 
overhauls  and  other  availabilities. 

•  Test  Gauges  -  Temporary  installation  of  mechanical  gauges  that  connect  to  fittings  designed 
and  installed  for  test  equipment  attachment.  The  use  of  test  gauge  fittings  for  other  than  test 
equipment  attachment  will  be  approved  by  the  SPM  before  usage. 

•  Temporary  Equipment  Alterations  in  the  form  of  ORDALTs,  MACHALTs,  FCs  AND  ECs. 

9-10.3  Definition 

A  TEMP  ALT  is  any  alteration  that  provides  new  or  improves  existing  capabilities  on  a 
temporary  basis  (not  to  exceed  one  year  or  one  operational  deployment  in  duration)  in 
support  of  Research  Development,  Test  and  Evaluation  (RDT&E)  or  military  exercise  or 
mission  requirements.  Budgeting  and  funding  for  TEMPALT  accomplishment  is  usually 
part  of  the  applicable  project  or  program  for  RDT&E  alterations,  or  the  cognizant 
FLTCINC,  TYCOM  or  CNO  Resource  Sponsor  for  mission  support  alterations. 
Budgeting  for  TEMPALTs  shall  include  sufficient  funding  to  remove  the  alteration  and 
restore  the  ship  to  its  original  configuration.  TEMPALTs  are  not  funded  as  part  of  the 
FMP. 

9-10.4  TEMPALT  Categories 

The  following  are  the  general  TEMPALT  categories: 

•  At-sea  testing  and  evaluation,  i.e.,  including  sea  trials,  fast  cruise,  SONAR 
certification,  and  weapon  or  missile  system  certification  trials 

•  Research  and  development 

•  Operational  Evaluation/Technical  Evaluation  (OPEVAL/TECHEVAL) 

•  Special  Mission/Battle  Group 

•  Military  Exercise  or  Contingency  Operations 

•  CS  PMIs  and  PSIs 

9-10.5  Policy 
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TEMPALTs  shall  be  reviewed  and  technically  approved  by  the  cognizant  SPM  before  being 
authorized  for  accomplishment  by  the  cognizant  TYCOM.  Alterations  that  are  intended  to  be 
installed  for  a  period  in  excess  of  one  year  or  one  operational  deployment  shall  be  considered  a 
permanent  change  to  a  ship’s  configuration  and  shall  be  accomplished  as  a  SHIP  ALT.  After 
completion  of  testing  requirements,  mission  or  exercise  support  requirements  or  one  year, 
whichever  comes  first,  TEMPALTs  must  be  removed  and  the  ship  restored  to  its  previous 
configuration.  The  activity  sponsoring  the  accomplishment  of  the  TEMPALT  shall  be 
responsible  for  funding  the  removal  of  the  TEMPALT  and  the  restoration  of  the  ship. 

If  the  intent/functionality  of  a  TEMPALT  is  accomplished  by  a  follow-on  SHIP  ALT,  that 
TEMPALT  will  be  cancelled  and  not  authorized  for  further  installations.  TEMPALT 
installation  drawings  that  are  not  developed  by  the  PY  shah  be  forwarded  to  the  PY  for 
review  and  approval. 

TEMPALTs  that  may  affect  Battle  Group  Interoperability  will  be  coordinated  with  the  cognizant 
CINC  /NAVSEA  53  prior  to  installation  scheduling. 

9-10.6  TEMPALT  Process 

TEMPALT  planning,  development  and  execution  closely  mirrors  the  process  for  permanent 
SHIP  AT, Ts.  The  sponsoring  activity  will  submit  a  JCF  to  the  cognizant  SPM  to  obtain  a 
TEMPALT  number  and  concept  approval.  However,  the  JCF  is  not  used  to  obtain  funding. 
Funding  associated  with  TEMPALTs  will  be  borne  by  the  sponsoring  activity  not  the  SPM. 

TEMPALTs  do  not  require  the  development  of  a  formal  document  like  the  SAR,  which  is 
required  for  SHIPALTs.  However,  alteration  design  development  for  TEMPALTs  is  the  same  as 
for  SHIPALTs.  A  Plan  of  Actions  and  Milestones  (POA&M)  will  be  developed  by  the 
sponsoring  activity  which  outlines  requirements  for  design  shipcheck,  design  development, 
drawing  approval,  assembly  fabrication,  testing  (e.g.  land-based,  pre-and-post  installation,  at-sea), 
alteration  accomplishment  and  alteration  approval.  The  POA&M  should  include  all  personnel 
associated  with  the  TEMPALT  during  its  entire  installed  timeframe,  as  well  as  the  identification 
and  mitigation  of  all  topside  impacts  to  the  CS.  The  SPM,  TYCOM  and  PY  are  required  to 
review  the  POA&M  and  provide  comments  to  the  sponsoring  activity.  The  SPM,  TYCOM  and 
PY  will  be  provided  copies  of  the  final  POA&M. 

After  the  POA&M  is  issued,  the  sponsoring  activity  must  coordinate  detailed  planning  with  the 
TYCOM  and  SPM  to  establish  which  ship  is  to  receive  the  TEMPALT  (if  not  previously 
identified  in  the  tasking  document)  and  to  determine  dates  that  the  ship  will  be  available  for 
design  shipcheck  and  alteration  accomplishment. 

TEMPALT  installation  drawings,  similar  to  SIDs  are  also  required.  The  sponsoring  activity  is 
responsible  for  developing  detailed  installation  drawings  and  for  providing  them  to  the  SPM  with 
adequate  time  for  the  applicable  PY  to  review.  Minimal  review  time  is  30  days. 

While  the  SPM  does  not  “certify”  the  adequacy  of  TEMPALT  logistics  products  as  it  does  for 
SHIPALTs,  and  the  FMP  ILS  Certification  Milestones  do  not  apply,  any  and  all  ILS  products  that 
will  be  provided  for  the  purposes  of  supporting  the  operation,  testing  and  maintenance  of  the 
TEMPALT  shall  be  documented  on  an  ILS  Certification  Form.  It  is  recommended  that  a 
completed  ILS  Certification  Form  be  provided  to  the  SPM  in  sufficient  time,  prior  to  installation, 
to  allow  the  SPM  ample  time  to  review  and  resolve  any  potential  supportability  issues 
surrounding  the  installation  and  support  of  the  TEMPALT  (preferably  4  months  prior  to 
installation,  but  NLT  2  months  prior  to  installation).  Furthermore,  TEMPALT  Configuration 
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Status  Accounting  (CSA)  requirements  shall  be  documented  in  the  ship’s  Current  Ship 
Maintenance  Project  (CSMP)  using  the  Departure  From  Specification  (DFS)  process  as  well  as 
through  the  CDMD-OA  process  used  for  SF1IPALTS. 

Scheduling  for  TEMPALTs  shall  be  performed  in  the  same  manner  as  SFIIPALTs. 

9-10.6.1  TEMP  ALT  Installation  and  Removal  Messages 

The  sponsoring  activity  will  notify  the  cognizant  SPM,  CINC,  and  TYCOM  by  naval  message 
when  any  TEMP  ALT  installation  is  accomplished  on  any  active  ship  and  when  any  TEMP  ALT 
installation  is  relocated  or  removed.  At  a  minimum,  installation  messages  will  contain  the 
TEMP  ALT  number  and  title,  ship’s  name  and  hull  number,  date  of  installation,  any  preliminary 
1LS  provided,  proposed  removal  date,  the  sponsoring  activity’s  point  of  contact  and  references  to 
the  SPM  approval  and  TYCOM’s  authorization.  In  addition,  the  installation  message  will  include 
a  statement  certifying  that  the  installation  was  accomplished  in  accordance  with  the  TEMP  ALT 
installation  drawings;  and  any  discrepancies  were  adjudicated  in  accordance  with  reference 
S9(aa),  as  applicable.  If  training  is  required,  the  installation  message  will  also  include  names  of 
ship’s  personnel  trained  to  operate  and  maintain  the  TEMPALT  equipment.  Removal  messages 
will  contain  the  TEMPALT  number  and  title,  ship’s  name  and  hull  number,  date  of  removal,  and 
a  statement  certifying  that  the  ship  was  restored  to  original  configuration  or  any  outstanding 
related  item  preventing  restoration. 

9-10.7  Responsibilities 

9-10.7.1  Sponsoring  Activity 

•  Identify  those  TEMPALTs  which  support  a  special  mission  for  the  duration  of  a  specific 
deployment  and  which  are  being  considered  for  class  and  multi-ship  approval. 

•  Provide  project  or  program  funding  and  coordination  for  all  phases  of  TEMPALT 
development,  including  detailed  design  packages,  installation,  and  restoration  of  the  ship  to 
its  original  configuration. 

•  Identify  installation  test  and  evaluation  requirements  of  all  TEMPALTs. 

•  Develop  the  TEMPALT  JCF  and  submit  to  the  SPM  for  approval. 

•  Develop  TEMPALT  installation  drawings. 

•  For  the  purpose  of  adjudicating  nonconformance,  TEMPALT  drawings  are  considered 
nondeviation  drawings.  In  cases  where  the  approved  TEMPALT  design  must  be  modified  to 
suit  a  particular  installation,  the  required  nonconformance  to  TEMPALT  design  will  be 
adjudicated  by  the  IA  in  accordance  with  DFS  procedures  of  reference  S9(aa)  Volume  V  Part 
1  Chapter  8. 

•  Develop  the  TEMPALT  POA&M. 

•  Ensure  that  the  design  documentation  for  TEMPALTs  has  been  approved  by  the  SPM  prior  to 
the  start  of  ship-work  in  accordance  with  the  policy  and  procedures  of  this  subsection. 

•  Ensure  that  authorization  has  been  obtained  from  the  applicable  TY COM  prior  to  installation. 

•  Ensure  all  TEMPALTs  impacting  CS  equipment  are  reviewed  by  the  CSE  as  well  as  the 
Warfare  Area  Manager  (WAM). 

•  Establish  a  MOA  for  all  work  to  be  performed  and  accomplish  all  work  in  accordance  with 
reference  S9(aa). 

•  Notify  the  SPM  and  applicable  TYCOM(s)  by  naval  message  whenever  a  TEMPALT  has 
been  accomplished,  relocated,  or  removed. 
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•  Provide  a  copy  of  the  approved  technical  data  package  to  the  ship  each  time  the  alteration  is 
accomplished. 

•  Provide  all  1LS  products,  including  Training,  required  for  the  operation  and  maintenance  of 
the  TEMP  ALT  equipment  during  its  installed  time  frame  or  use  aboard  ship. 

•  Provide  the  CDM  CDMD-OA  records  for  TEMP  ALT  equipment  after  installation. 


9-10.7.2  SPM 

•  Ensure  that  TEMPALTs  are  technically  satisfactory  (e.g.,  safe,  weight  and  moment,  stability, 
missile  hazard,  access  to  and  operation  of  vital  equipment,  etc.). 

•  Obtain  PY  review  and  input  on  TEMPALTs.  Ensure  ship  impacts  (e.g.  cabling,  foundations, 
new/relocated  equipment,  power,  etc.)  are  considered  in  TEMP  ALT  installation  drawings. 


9-10.7.3  TYCOM 

•  Authorize  accomplishment  of  only  those  TEMPALTs  that  have  been  approved  for 
accomplishment  by  the  SPM. 

•  Adjudicate  non-conformance  to  approved  TEMP  ALT  design  in  accordance  with  DFS 
procedures  or  Reference  S9(aa)  Volume  V  Part  I  Chapter  8. 

•  Maintain  administrative  control  and  monitor  installation  and  removal  of  TEMPALTs. 

•  Notify  CNO  when  authorizing  installation  of  TEMPALTs  that  may  impact  ship  mission  or 
operational  capabilities. 


9-10.8  Configuration  Status  Accounting  (CSA) 

CSA  for  TEMPALTs  shall  be  documented  in  CDMD-OA  as  it  is  for  SHIPALTs,  AERs,  and 
equipment  alterations,  as  well  as  the  ship’s  CSMP  using  the  DFS  process.  Configuration 
development  will  normally  be  to  the  top-level  configuration  to  provide  for  the  general 
identification  of  the  equipment  installed  by  the  TEMPALT.  This  allows  the  CDM  to  identify  the 
equipment  and  establish  a  Cl  record  in  CDMD-OA  for  purposes  of  CSA  once  the  installation  has 
been  validated  as  complete.  This  data  will  be  provided  by  the  sponsoring  activity  in  accordance 
with  the  requirements  of  references  S9(c)  and  S9(g)  and  Section  8  of  this  manual.  CSA  for 
TEMPALTs  shall  also  be  accomplished  utilizing  the  DFS  process  as  described  in  reference 
S9(aa)  Volume  V  Part  I  Chapter  8.  This  process  requires  that  the  DFS  be  entered  into  the  CSMP 
and  the  installing  activity  database  until  such  time  as  the  ship’s  original  configuration  is  either 
restored  or  permanent  approval  of  the  TEMPALT  is  authorized. 

Ship’s  Force  shall  provide  the  sponsoring  activity  a  DFS  number.  The  subject  line  of  the  DFS 
shall  read:  “DFS  Request-New  Technology  Test  Initiative.”  The  sponsoring  activity  shall 
provide  the  following  information  in  block  14  of  the  DFS. 

•  Description  of  TEMPALT.  (Include  anticipated  benefit) 

•  Product  and  Manufacturer 

•  Sponsoring  Agencies  (i.e.  Port  Engineer,  Depot  Facility,  SPM,  SPAWAR,  FTSCLANT, 
NSWC,  ISEA,  Contractors,  etc.) 

•  Technical  and  other  assists  if  required  (Ship’s  Force,  SIMA,  RRC,  etc.) 

•  Estimated  Date  of  Installation 
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•  Define  Test  initiative  and  compartment  location  (system,  equipment,  component,  hull 
structure,  etc) 

•  Describe  long/short  term  1LS  plans,  if  available  (for  parts  support,  other  new  maintenance 
requirements,  PMS,  and  technical  documentation) 

•  Provide  estimated  test  completion  date  and  sponsoring  agency  evaluation  POA&M 

Ship’s  Force  shall  forward  the  DFS  to  the  applicable  TYCOM  for  approval.  The 
TYCOM  shall  provide  a  copy  of  the  approved  DFS  to  the  requesting  ship  and  TEMP  ALT 
sponsor. 


83 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


84 


APPENDIX  B:  TEMPORARY  ALTERATION  DATA  PACKAGE 


OED  SCI  MLS  ARCHITECTURE 
LCC-19  (USS  BLUE  RIDGE) 


TEMP  ALT  TA134 

REV  (-) 


Prepared  By 

PMW-157-1F 

SPAWAR 


14  May  2003 
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TEMPORARY  ALTERATION 
(TEMP ALT)  DATA  PACKAGE 


USS  BLUE  RIDGE  (LCC-19) 

TEMPORARY  ALTERATION  BASELINE  SPECIFICATION 

OED  SCI  MLS  ARCHITECTURE 

Prepared  By: 

PMW-157-1F 

SPAWAR 


SUBMITTAL  DATE: 

ALTERATION  DATE: 

SUBMITTED  BY: 

14  May  2003 

TBD 

(SSC  San  Diego) 

REVIEWED  BY: 

SPAWAR 

John  Falbo 

DATE 

(04R-3) 

CNSP 

Bob  Buckley 

DATE 

(N43) 

APPROVED  BY: 

LT  Kevin  Pettit 

DATE 

(PMS  470) 

Joe  Dobrzynski 

DATE 
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INSTALLATION  BRIEF 


This  TEMPALT  Data  Package  provides  the  necessary  information  to  install  OED  SCI 
MSL  Architecture  aboard  the  USS  Blue  Ridge  (LCC-19).  This  OED  SCI  MSL 
Architecture  Force  Level  suite  of  equipment  consists  of  two  SCI  servers  (HP  J6000),  one 
SCI  OED  workgroup  switch  (OS-4024),  one  SCI  Media  Converter  (MILAN  9100X),  one 
Sun  Rave  Radiant  Mercury,  two  SCI  client  workstations  (HP  J6000),  one  SCSI 
Expansion  Chassis,  one  Disk  Storage  System  (DS2100),  and  one  JWICS  Router  in  Rack 
No.  1.  Additionally,  one  Coalition  server  (HP  J6000),  one  Media  Converter  (MILAN 
9100X),  one  Stoneghost  Metaframe  PC  Server  (V133-1 126),  one  Bison  Metaframe  PC 
Server  (V133-1 126),  one  JWICS  Metaframe  PC  Server  (V133-1 126),  one  Targeting 
client  workstation  (HP  J6000),  one  Collections  client  workstation  (HP  J6000)  and  six 
CISCO  2621  Routers  (Stoneghost,  Bison,  COWAN  A,  COWAN  C,  COWAN  J  and 
COWAN  K)  in  Rack  No. 2  will  be  supplied.  Also  required  on  the  SCI  Enclave  are  two 
(2RU)  Neptune  FPDs,  four  remote  SCI  Client  Workstations  (including  FPD,  KYBD  and 
TBALL)  and  seven  SCI  Client  Desktop  Workstations  (including  FPD,  KYBD  and 
TBALL).  A  100Mb  port  on  the  SCI  edge  switch  (ESXXXXX)  will  be  necessary  to 
provide  the  required  LAN  connectivity. 

There  will  be  1 15VAC/60Hz  power  requirements  for  the  uninterruptible  power  sources 
for  all  equipment.  Also,  all  drops  will  require  access  to  a  ships  power  panel,  which  has  a 
current  feed  sufficient  to  supply  1.5KVA  UPS. 

The  planned  equipment  installation  will  be  completed  NLT  than  TCD  which  is  TBD. 


SHIP  APPLICABILITY 

USS  Blue  Ridge  (LCC-19) 
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ALTERATION  BRIEF 


Project  Title: 


OED  SCI  MLS  Architecture  Installation  for  the  USS  Blue  Ridge 


Security  Classification:  SCI 


Sponsoring  Activity: 

Applicable  Ship: 

Applicable  TY COM: 
Overall  Port  Eng. 

Port  Engineer 

Alteration  Site: 

Alteration  Activity: 

Alteration  Duration: 

Alteration  Technical 
Supporting  Requirements: 


PMW-157 

USS  Blue  Ridge  (LCC-19) 

COMNAVSURFPAC 
Bob  Keyes  (619.556.0240) 
Charlie  Sutton  (0 1 1 .8 1 .80.3 1 1) 

Y okosuka,  JAPAN 

PMW-157 

SPAWARSYSCEN  San  Diego 
4301  Pacific  Highway 
San  Diego,  CA  921 10-3127 

One  year  (365  days) 


N/A 


ATTACHMENTS 

A.  Plan  of  Action  and  Milestones  (POA&M) 

B.  Temporary  Alteration  Impact  Data 

C.  Stress  Calculations  (N/A) 

D.  Calculated  Weight  and  Moments  Record 

E.  Integrated  Logistics  Support  (ILS)  General  Information 
Removal/Exit  Plan 

OED  SCI  MLS  Architecture  Installation,  LCC-19  Tempalt  Installation  Drawings 


REFERENCES 

NAVSEA  TECHSPEC  9090-3 10D  Alterations  to  Ships  Accomplished  by  Alteration  Installation 
Team. 

SSCSDINST  4720.1  Shipboard  Installation  Guidance 

SWRMCINST  4790.3  SWRMC  Structure,  Policies  and  Procedures 

SPAWAR  C4I  Temporary  Alterations  Guidelines,  Version  4,  DTD  October  29,  2002 
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OED  SCI  MLS  Architecture  Force  Level  System  Installation 

The  purpose  of  this  TEMP  ALT  is  to  improve  functionality;  refresh  technology  and  provide  multi¬ 
level  all  source  intelligence  fusion,  analysis  and  dissemination.  Provides  single  common  desktop 
solution  for  accessing  multiple  security  domains.  This  is  accomplished  through  the  introduction 
of  Coalition,  Stoneghost,  Bison,  JWICS  and  SCI  Backup  servers  on  the  SCI  enclave. 

OED  SCI  MLS  Architecture  Force  Level  interface  requirements  include: 

1 15 VAC,  60Hz,  single  phase  power: 
two  20A  circuit  breaker  located  in  FIC 

additional,  potential  UPS  sources  to  be  identified  near  workstation  locations. 

SCI  port  availability  at  100Mb. 

Use  available  ports  on  ESXXXXX  located  in  FIC 
SCI  LAN: 

SCI  server,  qty.  2  (HP  J6000) 

Coalition  server,  qty.  1  (HP  J6000) 

Stoneghost  PC  server,  qty.  1  (Vision  V133-1 126) 

Bison  PC  server,  qty.  1  (Vision  V133-1 126) 

JWICS  PC  server,  qty.  1  (Vision  V133-1 126) 

Sun  Rave  Radiant  Mercury,  qty.  1  (RM2DIA-AX1 105) 

SCSI  Expansion  Chassis,  qty.  1 
Disk  Storage  System,  qty.  1  (DS2100) 

IWO  Client  Workstation,  qty.  1  (HP  J6000) 

AIWO  Client  Workstation,  qty.  1  (HP  J6000) 

Targeting  Client  Workstation,  qty.  1  (HP  J6000) 

Collections  Client  Workstation,  qty.  1  (HP  J6000) 

PDA,  qty.  2  (1RU) 

Neptune  FPD,  qty.  2 
Router,  qty.  7  (CISCO  2621) 

Media  Converter,  8  port,  qty.  2  (MILAN  9100X) 

24  Port  Workgroup  Switch,  qty.  1  (OS  4024) 

UPS  power  source,  qty.  9 

NEC  FPD  workstation,  qty.  2  (LCD  1850X) 

GCCS-M  software 
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The  detailed  hardware  list  is  as  follows 
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This  installation  will  have  no  impact  on  ship’s  systems  or  safety.  Pre  and  post 
installation  testing  will  be  accomplished  by  ship’s  force  to  ensure  no  tactical  system 
degradation  has  occurred  as  a  result  of  the  installation  or  removal  of  this  TEMP  ALT. 


ATTACHMENT  A 

PLAN  OF  ACTION  AND  MILESTONES  (POA&M) 

1 .  Perform  Ship  In-Brief  and  Ship  Survey  -  TBD 

2.  Submit  TCCP  to  04R3  for  Development  of  TJCF  05/14/03 

3.  Submit  Non-Standard  Offer  Message  to  FLTCOM  /  TYCOM  DTG 

4.  Submitted  to  eCCB  (If  Applicable)  N/A 

5.  Approval  of  TCD  Waiver  (If  Applicable)  DTG 

6.  Receive  Authorization  for  Install  from  FLTCOM  /  TYCOM  -  DTG 

7.  Develop  Drawing  and  TEMP  ALT  Data  Package  -  06/01/03 

8.  Submit  TEMP  ALT  Data  Package  to  04R-3D  for  review  -  05/14/03 

9.  ILS  support  Documentation  -  06/15/03 

10.  Assembly  Fabrication  (If  Applicable)  05/20/03 

11.  Submit  TEMP  ALT  to  SPM  for  approval  -  05/27/03 

12.  Receive  Approval  from  Ship  Program  Manager  (SPM)-  06/02/03 

13.  Perform  RMMCO  Check-in  -  06/02/03 

14.  Begin  Equipment  Installation  -  06/09/03 

15.  Complete  Installation  -  06/22/03 

16.  Perform  RMMCO  Checkout  -  06/30/03 

17.  Perform  RMMCO  Check-in  for  Removal  -  06/01/04 

18.  Begin  TEMP  ALT  Removal  -  06/08/04 

19.  Complete  Removal  -  06/22/04 

20.  Perfonn  RMMCO  Checkout  -  06/22/04 
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ATTACHMENT  B 


TEMPORARY  ALTERATION  IMPACT  DATA 

1  Shipboard  Location: 

1 . 1  TEMP  ALT  Equipment  -FIC  (3-67-0-Q),  N2  Office  Space  (3-57-0- 
Q),  Cryptology  Office  (3-81-1-Q),  and  SUPPLOT  (2-88- 1-C) 

2  Power  Requirements:  1 15 VAC,  60Hz,  single  phase 

3  Power  Source:  Ships  Power  Distribution  Breaker/Fuse  Panels  (two  20A 
Circuits) 

4  Inputs  to  Alteration: 

•  Ship’s  115  VAC,  60  Hz,  single  phase  power 

•  100Mb  connection  to  SCI  LAN 

5  Outputs  from  Alteration:  100Mb  connection  from  associated  Backbone  or  Edge 
switch. 

6  Impact  on  Ship’s  System: 

6.1  Weight/Moment: 

Added  weight  (Net):  1183  lbs  (I) 

VM:  50.44  VCG 

LM:  7.6  LCG  (F) 

TM:  22.5  TCG  (P) 

6.2  Ship  Dynamics:  No  Impact 

6.3  Maneuverability:  No  Impact 

6.4  Tanks:  No  Impact 

6.5  Habitability:  No  Impact 

6.6  EMI/RFI:  No  Known  Impact 

6.7  Communications  Security  (TEMPEST):  Cables  associated  with  this 
TEMP  ALT  will  be  fabricated  in  accordance  with  NSTISSAM  TEMPEST 
2-95  with  amendment  2-95A  and  IA-PUB-5239-31 

6.8  System(s)/Equipment(s)/Capability(ies)  Disabled: 

No  Impact 

6.9  Equipment  Rip-out:  No  Impact 

6.10  Heat  Load:  No  Impact 

7  Impact  on  Safety: 

7.1  Watertight  Integrity:  No  Impact 

7.2  Subsafe:  Not  Applicable 

7.3  Life  Support:  No  Impact 

7.4  Personnel  Safety:  No  Impact 

7.5  Existing  Equipment  Safety:  No  Impact 
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8.  Testing: 


8.1  All  new  cables  will  be  tested  by  the  installing  activity  for  continuity  and 
insulation  resistance. 

8.2  Pre  and  post  installation  testing  and  pre  and  post  removal  testing  of  the 
shipboard  sy stem/ equipment  will  be  performed  by  ship’s  force  to  ensure 
no  system  degradation  has  occurred  as  a  result  of  installation  or  removal 
of  the  TEMP  ALT. 
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ATTACHMENT  C 


STRESS  CALCULATIONS 


The  equipment  involved  in  this  installation  is  not  of  sufficient  weight  or  size  to  require 
stress  calculations.  No  formal  stress  analysis  for  this  TEMP  ALT  is  warranted. 
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ATTACHMENT  D 


CALCULATED  WEIGHT  AND  MOMENTS  RECORD 

The  net  increase  in  weight  from  this  TEMP  ALT  is  negligible  (1183  lbs): 


(D  O 
O  Lt_ 


CD 
cd  o 

O  LL 
'  LU 
CL 


CD  m 

O  ti. 

>  W 

CL 


—  CL 
X  X 
CL  CL 

-  O 


<  CD 
*1 


O  O 


O  £ 


^  x  Q 
H  CD  Z 
P  LU  2 


II 


<  Z 
2  O 
Z  CO 
O  Z 


ATTACHMENT  E 


INTEGRATED  LOGISTICS  SUPPORT  (ILS) 


Spare  parts  and  special  test  equipment  are  not  required  to  maintain  the  equipment.  Parts 
support  for  all  of  the  POR  equipment  will  be  provided  by  NAVICP  and  any  onboard 
allowances  will  be  determined  at  a  later  time.  SPAWAR  will  provide  interim  operator 
training  at  the  time  of  installation.  Maintainer  training  will  not  be  required  as  all 
equipment  is  POR.  All  follow-on  training  is  provided  using  OED  SCI  MLS  Architecture 
computer  based  training  CD.  There  is  also  a  help  file  built  within  the  software. 

Technical  support  will  be  available  through  their  website 

https://www.idms.spawar.navv.mil.  A  1-800-838-1816  number  is  also  available  for 
further  help. 

No  COSAL  is  warranted  or  has  been  developed  for  this  TEMP  ALT. 

An  OED  SCI  MLS  Architecture  Installation  TEMP  ALT  Integrated  Logistics  Support 
Certification  Form  has  been  completed  for  this  TEMP  ALT  and  can  be  viewed  on  the 
PMW  157  website  https://mccs.spawar.navy.mil/index.cfm. 

For  any  COSAL  and  /  or  ILS  questions,  comments  or  requests  contact  Tim  Green  of 
SPAWAR  System  Center  San  Diego,  (858)  537-0598,  tim.green@navy.mil. 


ATTACHMENT  F 
REMOVAL/EXIT  PLAN 


At  the  completion  of  the  ship’s  deployment,  USS  Blue  Ridge  will  coordinate  with 
COMNAVSURFPAC  N43  and  USJFCOM  to  determine  the  disposition  and  removal 
schedule  of  this  TEMP  ALT. 

The  current  planned  dates  for  equipment  removal  and  de-installation  is  TBD. 
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APPENDIX  C:  LCC-19  OED  TEMP  ALT  ARRANGEMENT 

DRAWINGS 
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APPENDIX  D: 


LCC-19  OED  TEMP  ALT  CABLE  BLOCK 
DIAGRAM 
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55”  OED  SERVER  RACK  A 

(NPL  6) 


I 


TO  SHEET  3  ZONE  22-F  P/O  55”  OED  SERVER  RACK 


TO  SHEET  5  ZONE  38-F  P/O  55"  OED  SERVER  RACK  B 


Ill 
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APPENDIX  E: 


OED  TEMPALT  ILS  CERTIFICATION 
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ADDENDUM  Humber:  |  Revision  Datef 

Date  ILS  Certification  Form  prepared:  Q5.Mav.2QQ3 _ 

If  revised,  date  and  revision  number  of  this  ILS  Certification  form  (DP  MMM  YYYY)/Rev  #: 
ILS  Certification  Form  for  Alteration  Number(s):  TA0000K  (LCC  19  -USS  Blue  Ridge) 
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LCC  19 
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LCC  19 

LCC  19 

LCC  19 

LCC  19 

LCC  19 

LCC  19 

LCC  19 

LCC  19 

LCC  19 

ms  or 

PBL 

Equipment  Identification 

1RU  PDA  vV  cables 
(Power  Distribution  Unit) 

1RU  SCSI  Expansion  Chassis 

Neptune  Flat  Panel  Display 

Server  Non  Rugged  HP-J6000  Racfenmirt 

Server  Non  Rugged  HP-J6000 

Desktop 

JBOD  DS2100 

Radiant  Mercury  -  Sun  Rave 

1RU  PC  Server 

Switch ,  SCI 

Chassis,  Media  Converter.  8  port  Milan 

Module  Converter.  lOBaseT-IOBase-FL 

- HSN  or  Cage  7 

Part  Number 

Cage:  61099 

P/N:  112-32500 

NSN:  7GH5895-LL-H7A-7991 

Cage:  61099 
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Hull(s) 

Applicability 

LCC  19 

LCC  19 

LCC  19 
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LCC  19 

LCC  19 

LCC  19 

LCC  19 

LCC  19 

LCC  19 

LCC  19 
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MSD  / 
PBL 

Equipment  identification 
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Media  Converter  Redundant  Power  Supply 

Switch  8-port.  Fiber  UPLINK 
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2  4  KVA  UPS  CLARY 
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Note  1:  All  system  support  is  provide  by  contacting  the  OED  POC  Maureen  Myerat  619-553-3979  ormyerrateDawar.naw.mil 
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Provide  name,  code,  telephone  number  and  E-mail  Address  for  Intermediate/Depot  level  maintenance  requirements: 


SUPPORT  AMD  TEST  EQUIPMENT  REQUIREMENTS 
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|  B.  Is  Initial  Training  Required?  (Yes  or  Ho):  No 
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JQR  Number  Title  Model  Manager  n  Qualification  Description 


JQR  Number  Title  Model  Manager  n  Qualification  Description 
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Date  ILS  Certification  Form  prepared:  05  May  2Q.Q3  I  Revision  Date: 

If  revised,  date  and  revision  number  of  this  ILS  Certification  form  (DD  MMM  YYYY)/Rev  #: 

ILS  Certification  Form  for  Alteration  Number(s):  TA0000K  (LCC  19  -USS  Blue  Ridge) 

Alteration  Type:  TEMPALT _ _ 

Alteration  Title  and/or  Brief:  OSIS  (Ocean  Surveillance  Information  System)  Evolutionary  Development  (QED ) 
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APPENDIX  F:  TABLE  OF  NAVY  REFERENCE  MESSAGES 


FLEET  GENERATE] 

D  REQUIREMENTS  REFERENCES 

MSGID 

FROM 

SUBJECT 

021132Z  JAN  04 

COMENTSTRKGRU 

OED  MID-CRUISE  REPORT 

PARA  2.  CURRENT  EMPLOYMENT.  OED  IS  USED  DAILY  BY  COMENTSTRKGRU  AND 
COMDESRON  EIGHTEEN  STAFF  AND  ENTERPRISE  INTELLIGENCE  AND  CRYPTOLOGIC 


PERSONNEL  AS  AN  ALL-SOURCE  INTELLIGENCE  ANALYSIS  TOOL  AND  AUTOMATED  MESSAGE 
HANDLING  SYSTEM.  OED'S  ABILITY  TO  RECEIVE,  QUEUE,  AND  FORWARD  RECORD  MESSAGE 
TRAFFIC  FROM  UNCLASSIFIED  THROUGH  SCI  COMPARTMENTS  (HCS  AND  GG  PARTICULARLY), 
HAS  IMPROVED  WATCHSTANDERS'AND  LEADERSHIP'S  ABILITY  TO  REVIEW  TRAFFIC  IN  ONE 
PLACE  WITHOUT  HAVING  TO  ACCESS  MULTIPLE  SYSTEMS  AND  INDIVIDUAL  QUEUES  LEADING 
TO  TIME  SAVINGS  AND  INCREASED  EFFICIENCY.  OED'S  MLS  FUNCTIONALITIES  FOR  MESSAGE 
PROCESSING/HANDLING,  LONG  TERM  TRACK  DATA  ANALYSIS,  ACCESS  TO  SCI  INTELINK  AND 
PRE-LOADED  NATIONAL  DATABASES,  AND  SCI  CHAT  HAVE  PROVEN  TO  BE  BOTH  INNOVATIVE 
AND  HIGHLY  EFFICIENT  AS  THEY  PROVIDE  A  PREVIOUSLY  UNAVAILABLE  MEANS  ABOARD  A 
CV(N)  TO  WORK  WITH  BOTH  GENSER  AND  SCI  MATERIAL  ON  ONE  WORKSTATION. 

PARA  5.  ORIG  RATES  OED  AS  A  QUALIFIED  SUCCESS  AND  ENDORSES  ITS  CONTINUED 
INTEGRATION  INTO  ADDITIONAL  CVICS. 


MSGID 

FROM 

SUBJECT 

220115Z  NOV  03 

COMSECONDFLT 

SUBJ/OSIS  EVOLUTIONARY  DEVELOPMENT  (OED) 
UPDATE  (SERIAL  3):  OED  /FLEET  INTELLIGENCE 
REQUIREMENTS 

PARA  1.  THE  OED  INTELLIGENCE  ARCHITECTURE  PROVIDES  AN  MLS  ENVIRONMENT  WHOSE 

FOUNDATION  OFFERS  A  REALIZABLE  OPPORTUNITY  FOR  A  CROSS  DOMAIN  SOLUTION  (CDS) 
THAT  SPANS  THE  COLLATERAL  AND  SCI  ENVIRONMENTS. 

PARA  3.  C2F  OED  UTILIZATION.  OED  ENABLES  INTELLIGENCE  PRODUCTION  AT  THE  SCI  LEVEL, 
AND  AUTOMATIC,  RAPID,  RELIABLE  DISSEMINATION  INTO  THE  COLLATERAL  ENVIRONMENT 
OF  THE  WARFIGHTER.  A.  C2F/CSFL  CURRENTLY  USES  OED  TO  SUPPORT  DAILY  JIC  WATCH 
INTELLIGENCE  REQUIREMENTS.  C2F/CSFL  J2  HAS  AN  OED  SERVER  AND  FIVE  WORKSTATIONS 
(THREE  IN  JIC  SPACES,  ONE  IN  J2  OFFICE,  AND  ONE  IN  J2  STAFF  SPACES).  OED  IS  CURRENTLY 
ACCREDITED  AND  HAS  FULL  NETWORK  ACCESS  TO  JWICS  AND  SCI  MSG  TRAFFIC,  AND  CAN 
TRANSMIT  TO  COLLATERAL  (U.S.  AND  NATO)  RECORD  MESSAGE  SYSTEMS.  C2F/CSFL  OED 
CURRENTLY  PROCESSES  MESSAGES  TO  THE  FLEET  SIPRNET  ENVIRONMENT  VIA  A  GCCS-M 
SERIAL  CONNECTION,  ALLOWING  AUTOMATIC  DISSEMINATION  OF  OPERATIONAL  TRAFFIC. 
LIKEWISE,  OED  PROCESSES  NATO  MSG  TRAFFIC  (SEND/RECEIVE)  INTO  THE  COLLATERAL 
ALLIED  INFORMATION  MESSAGE  SYSTEM  (AIFS/AIMS).  OED  PASSES  INFORMATION  VIA  A  LIVE 
MLS  FILTER  FEED  WHICH  IS  AUTOMATICALLY  AND  SEEMLESSLY  DOWNGRADED  TO  SECRET 
AND  NATO  SECRET  LEVELS  IN  NON-SCIF  SPACES.  OVER  100  HIGH  INTEREST  MERCHANT 
MESSAGES  HAVE  BEEN  PROCESSED  TO  THE  COLLATERAL  WORLD  WITHOUT  ERROR  IN  A  TRUE 
MLS  FASHION.  THE  BENEFIT  IS  THAT  THREAT  SHIP  UPDATES  ARE  AUTOMATICALLY  PASSED  IN 
A  TIMELY  MANNER  TO  OPERATION  NOBLE  EAGLE  SUPPORT  SHIPS  AND  SQUADRONS  VIA 
RELIABLE  AND  ACCURATE  MULTIPLE  SECURITY  LEVEL  METHODOLOGY. 

B.  ADDITIONAL  FUNCTIONS  SUPPORTING  JIC  WATCH  REQUIREMENTS  INCLUDE: 

-WATCHST ANDERS  SEARCH  ARCHIVED  MESSAGES  FOR  THEMATIC  ISSUES  AND  KEYWORDS. 
THESE  SEARCHES  OCCUR  ACROSS  MULTIPLE  SECURITY  LEVELS,  SAVING  WATCHSTANDER 
TIME  AND  ALLOWING  MORE  TIME  FOR  ANALYSIS. 

-OED  ALLOWS  WATCHST  ANDERS  TO  TRACK  VESSEL  MOVEMENT  THROUGH  TIME,  SUPPORTING 
WATCH  SITUATIONAL  AWARENESS  REQUIREMENTS. 

-MESSAGE  TRAFFIC  IS  AUTO  FORWARD  TO  WATCHSTANDER  JWICS  ACCOUNTS  BASED  ON  OED 
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USER-DEFINED  PROFILES. 

C.  C2F/CSFL  NEAR  TERM  OBJECTIVES.  HOW  WE  WILL  BETTER  USE  THE 
FUNCTIONALITIES  ALREADY  EXISTING  IN  OED. 

(1) .  EXPAND  USE  OF  OED  TO  IMPROVE  HLS/HLD  ANALYSIS  AND  OPERATIONAL  SUPPORT. 
-DISSEMINATE  EVENT-BY-EVENT  HIGH  INTEREST  MERCHANT  SUPPORT  TAILORED  TO  C2F 
RESPONSIBILITIES  FOR  INTEGRATION  INTO  THE  COP. 

-DISSEMINATE  DAILY  AT/FP  SUPPORT  MESSAGE  TO  U.S.  AND  NATO  AUDIENCE  TAILORED  TO 
C2F/CSFL  RESPONSIBILITIES. 

(2) .  EXPAND  OED  USE  TO  SUPPORT  J2  USERS  AT  ANY  JWICS  SCI  WORKSTATION. 
-AUTO-DISTRIBUTE  ALL-SECURITY  LEVEL  MSG  TRAFFIC  AND  SCI  E-MAIL 
BASED  ON  USER  DEFINED  DISSEMINATION  PROFILES. 

(3) .  EXPAND  C2F/CSFL  ORGANIC  SYSADMIN  SKILLS  AND  CAPABILITIES  TO 
LOOSEN  LIFE-LINE  ON  CONTRACTOR  SUPPORT. 

-CREATE  SCRIPTS  TO  HANDLE  BASIC  DAY  TO  DAY  SYSADMIN 

-DEVELOP  EXPERTISE  RECOGNIZED  AS  THE  FLEET  STANDARD  THAT  ENABLES  ACCESS  TO 
PRIVILEGES  NECESSARY  FOR  COMPREHENSIVE  IN-HOUSE  SYSTEM  MANAGEMENT. 


MSGID 

FROM 

SUBJECT 

151130Z  SEP  03 

USS  BLUE  RIDGE 

SUBJ/JOINT  MESSAGE  HANDLING  SYSTEM  (JMHS) 
REPLACEMENT 

PARA  3.  AN  EXAMPLE  OF  A  MORE  POWERFUL  MESSAGE  HANDLING  SYSTEM  IS  THE  OSIS 
EVOLUTIONARY  DEVELOPMENT  (OED)  SYSTEM  THAT  WAS  RECENTLY  INSTALLED  IN  SUPPORT 
OF  SCI/GENSER  INTELLIGENCE  MESSAGE  HANDLING.  THE  COMMAND  SHIP  STRONGLY  DESIRES 
THE  FLEXIBILITY,  SPEED  AND  EFFICIENCY  NOTED  IN  THE  OED  MESSAGE  HANDLER 

PARA  4.  USS  BLUE  RIDGE  STANDS  READY  TO  WORK  WITH  SPA  WAR  TO  IDENTIFY,  TEST  AND 
INSTALL  THE  NEXT  GENERATION  OF  MESSAGE  HANDLER 


MSGID 

FROM 

SUBJECT 

180901Z  SEP  03 

JAC 

MOLESWORTH 

OED  PROGRAM  SUPPORT 

PARA  1.  REQUESTS  CONTINUATION  OF  OED  RDT&E,  OMN,  OPN  SUPPORT  DUE  TO  THE 
CRITICALITY  OF  OED  TO  THE  JAC’S  MISSION. 


MSGID 

FROM 

SUBJECT 

211846Z  AUG  03 

COMLANTFLT  / 
N2/N3 

OED  SUPPORT  TO  THE  FLEET 

CLASSIFIED  -  “PARA  3  (U)....COMLANTFLT  REQUIRES  CONTINUED  CONTACT  REPORTING  AND 
REQUESTS  JFIC  CONTINUE  TO  HOST  [OED]  AND  OPNAV  N612,  ONI-4  AND  PMW-157  CONTINUE  TO 
REOURCE  THIS  CRITICAL  SUPPORT  TO  THE  FLEET.” 


MSGID 

FROM 

SUBJECT 

030845Z  JUL  03 

C7F 

FLEET  BATTLE  EXPERIMENT  KILO  QUICKLOOK 

PARA  6.  INITIATIVE  AREA  THREE:  JOINT  FIRES. .  ..A  RAPIDLY  RECONFIGURABLE  AND  RELIABLE 

TECHNOLOGY  THAT  CAN  QUICKLY  MEET  SECURITY  APPROVALS  MUST  BE  IN  PLACE  SO  THAT 
COALITION  PARTNERS  CAN  ARRIVE  IN  AN  AOR  AND  QUICKLY  BECOME  PARTICIPANTS  IN  AN 
EXISTING  FIRES  NETWORK. 


MSGID 

FROM 

SUBJECT 

281346ZMAR03 

CFFC  N6  /  N2 

FLEET  REQUIREMENTS  FOR  A  MULTI  LEVEL  SECURE 
(MLS)  SOLUTION 

PARA  3.  ISSUE:  IN  TODAY'S  ENVIRONMENT  OF  TIME  SENSITIVE  AND  COALITION  OPERATIONS, 
A  MLS  SYSTEM  IS  INCREASINGLY  IMPORTANT  TO  IMPROVE  COMMUNICATION  EFFICIENCY 
AND  INCREASE  SPEED  OF  INTELLIGENCE  EXCHANGE  AMONG  ALLIES  AND  COALITION 
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PARTNERS.  DESPITE  EFFORTS  BY  ALCON,  TO  DATE  THERE  REMAINS  NO  SINGLE  IDENTIFIED 
SOLUTION  THAT  PROVIDES  THE  FLEET  AN  ACCREDITED  MLS  NETWORK  THAT  BRINGS 
TOGETHER  THE  COMPLEX  ARRAY  OF  GENSER  AND  SCI  STOVEPIPES  (COWAN  A,  CENTRIXS  TIER 
1,  NIDTS,  CLOCE,  STONEGHOST,  BISON,  ETC.)  USED  BY  THE  FLEET  TODAY. 

PARA  4.  REQUIREMENT:  A  SINGLE  NETWORK  EQUIPPED  WITH  COMMON  APPLICATIONS  THAT 
HANDLES  AND  AGGREGATES  DATA  OF  VARIOUS  SECURITY  LEVELS  ACROSS  BOTH  SCI  AND 
COLLATERAL  DOMAINS  WITHIN  AN  ACCREDITED  MLS  ARCHITECTURE  /  OPERATING  SYSTEM. 


MSGID 

FROM 

SUBJECT 

281159Z  MAR  03 

C2F/C3F 

NUMBERED  FLEET  TOP  TEN  INFORMATION 
TECHNOLOGY  REQUIREMENTS 

PARA  5.  MULTIPLE  LEVEL  SECURITY  (MLS).  MULTIPLE  LEVEL  SECURITY  SHOULD 
PROVIDE  THE  FULL  RANGE  OF  COLLABORATION  CAPABILITIES  ACROSS  NUMEROUS 
NETWORKS  OF  DIFFERENT  SECURITY  CLASSIFICATION  LEVELS,  TO  INCLUDE  SEAMLESS 
EXCHANGE  OF  EMAIL,  WEB  PRODUCTS,  FILE  SHARING  AND  CHAT. 


MSGID 

FROM 

SUBJECT 

111450Z  MAR  03 

COMSECONDFLT 

SCI  NETWORK  SUPPORT  REQUIREMENTS 

PARA  3.  REQUIREMENT.  THE  NUMBERED  FLEET  SCI  INFRASTRUCTURE  IS  THE  BACKBONE  FOR 

INTELLIGENCE  EXCHANGE  BETWEEN  THE  NATIONAL  COMMUNITY,  THE  WATERFRONT,  AND 
DEPLOYED  UNITS.  EFFECTIVE  SUPPORT  TO  TACTICAL  FORCES  FROM  THE  OPERATIONAL 
LEVEL  OF  COMMAND  IS  SEVERELY  DEGRADED  WITHOUT  A  ROBUST  AND  OPERATIONALLY 
RELIABLE  SCI  INFRASTRUCTURE.  EXPANDING  MISSIONS  (TO  INCLUDE  HLS/HLD  FOR  C2F  AND 
C3F)  AND  TAILORED  MULTI-LEVEL  SECURITY  SUPPORT  TO  TACTICAL  UNITS,  AS  WELL  AS 
EXPANDED  INTEGRATION  WITH  JOINT  OPS  THROUGH  THE  FUNCTIONALLY  INTENSE  JOINT 
FORCE  MARITIME  COMPONENT  COMMANDER  (JFMCC)  REQUIRE: 

A.  HARDWARE  AND  SOFTWARE  MAINTENANCE  TO  INCLUDE  REFRESH. 

B.  OPERATIONAL  AND  MAINTENANCE  TRAINING. 

C.  TECHNOLOGY  GROWTH  APACE  OF  EVOLVING  ANALYTICAL  AND  MULTI-LEVEL  SECURITY 
NEEDS. 

D.  ABILITY  TO  TRANSITION  SEAMLESSLY  BETWEEN  AFLOAT  AND  ASHORE  OPERATIONS. 


MSGID 

FROM 

SUBJECT 

262206Z  FEB  03 

COMENTBATGRU 

REQUEST  FOR  OED  INSTALLATION 

SUMMARY:  REQUEST  TO  C2F  FOR  SUPPORT  OF  OED  INSTALLATION  ONBOARD  USS  ENTERPRISE 

(CVN  65) 


MSGID 

FROM 

SUBJECT 

211942Z  FEB  03 

COMSECONDFLT 
(COORDINATED 
COMSECONDFLT 
/  COMTHIRDFLT 
MESSAGE) 

SEA  POWER-21  IMPLEMENTATION  MESSAGE  NR-3; 
OPERATIONAL  AGENT  REQUIRED  WARFIGHTING 
CAPABILITIES  LIST  (U) 

“C2F  AND  C3F  IN  PARTNERSHIP  WITH  THE  OTHER  NUMBERED  FLEETS,  DEVELOPED  AN  INITIAL 
LIST  OF  REQUIRED  WARFIGHTING  CAPABILITIES  WHICH  WAS  PRESENTED  AT  THE  FIRST 
MEETING  OF  THE  SEA  TRIAL  EXECUTIVE  STEERING  GROUP  (STESG)  ON  13  FEB  03.  “ 


“PARA  6.  SEA  BASING  IMPROVE  AND/OR  DEVELOP 

A.  JOINT  FORCE  MARITIME  COMPONENT  COMMANDER  (JFMCC)  CONCEPT 

B.  COLLABORATIVE  INFORMATION  ENVIRONMENT 

C.  MULTI-NATIONAL  COMMAND  AND  CONTROL  INTELLIGENCE  INFORMATION  MANAGEMENT, 
ANALYSIS,  AND  FUSION  SUPPORT  TOOLS  MULTI-LEVEL  SECURITY  STANDARDIZED  COALITION 
IT  CONNECTIVITY” 
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MSGID 

FROM 

SUBJECT 

101447ZDEC02 

COMSECONDFLT 

OSIS  EVOLUTIONARY  DEVELOPMENT  (OED) 

AFLOAT:  EVALUATION 

PARA  3.  EVALUATION. 

SUMMARY:  OVERALL,  OED  IS  A  FLEXIBLE,  RELIABLE  ANALYTICAL  SUPPORT  SYSTEM  FOR  USE 
AT  SEA.  OED'S  ANALYSIS  TOOLS  WERE  ENABLERS  FOR  THE  FUSION  PROCESS  IN  A  SINGLE 
WORKSTATION.  DESIGNED  FROM  THE  START  TO  SUPPORT  MULTI-LEVEL-SECURITY 
INTELLIGENCE  ANALYSIS,  OED'S  EXISTING  ACCREDITATION  PROVIDES  A  SOLID  FOUNDATION 
FOR  RAPID  MODIFICATION  TO  ENABLE  INTELLIGENCE  SUPPORT  TO  COALITION  OPERATING 
ENVIRONMENTS.  THE  OED  SYSTEM  HAS  UNTAPPED  POTENTIAL  TO  BE  THE  CORE  OF 
INTEGRATION  EFFORTS  FOR  NAVY  INTELLIGENCE  CENTERS  AFLOAT. 

PARA  5.  A  FLOAT  VISION  FOR  OED. 

A.  ABILITY  TO  OPERATE  IN  THE  MULTI-NATIONAL  ENVIRONMENT  IN  THE  AFLOAT  JIC  AS  WELL 
AS  WITH  EXTERNAL  PARTNERS. 

B.  ABILITY  TO  RECEIVE  AND  MANIPULATE  IMAGERY. 

C.  ABILITY  TO  OVERLAY  AND  DISPLAY  SIMILAR  EVENTS  REPORTED  BY  MULTIPLE 
INTELLIGENCE  DISCIPLINES  (E.G.,  IMAGERY,  MASINT,  ELINT,  COMINT)  IN  THE  SAME  GEO¬ 
REFERENCE  FRAME. 

D.  MLS  DATABASE  TO  HAVE  HTML  DATA-CONTENTS  TAGS  AS  WELL  AS  SECURITY  LABELS. 

E.  ABILITY  TO  HAVE  DIRECT  DATA  AND  VOICE  (VOICE  OVER  IP)  INTEROPERABILITY  WITH 
OTHER  OED  SITES  (INCLUDING  NON-U.S.). 

F.  ABILITY  TO  INTERFACE  WITH  COALITION  INTELLIGENCE  DATABASES  SUCH  AS  NATO 
BATTLEFIELD  INFORMATION  COLLECTION  AND  EXPLOITATION  SYSTEM  (BICES).  AS 
INFORMATION  IS  PULLED  FROM  THESE  DATABASES,  OED  APPLICATIONS  WOULD  ALLOW  THE 
INFORMATION  TO  BE  GRAPHICALLY  DISPLAYED  AND  FUSED  INTO  A  COMMON  OPERATING 
PICTURE.  OED  WOULD  PRESERVE  THE  ORIGINAL  NATO  RELEASABILITY  OF  THIS  INFORMATION 
AS  IT  IS  FUSED  IN  AN  ALL-SOURCE  INTELLIGENCE  ENVIRONMENT. 


MSGID 

FROM 

SUBJECT 

132202ZAUG02 

COMTHIRDFLT 

JCSBG  INTELLIGENCE  LESSONS  LEARNED 

PARA1.B:  “STRONGLY  ENDORSE  THE 

CONTINUALLY  IDENTIFIED  FLEET  REQUIREMENT  FOR  A 

MULTI-LEVEL  SECURITY  SYSTEM  AFLOAT.”  “WRT  OED,  INFORMAL  LIAISON  MENTIONED  IN 
REF  A  SHOULD  MOVE  TO  A  FORMAL  LOOK,  IN  THEATER  AT  JICPAC,  AND  AFLOAT  ABOARD 
MOUNT  WHITNEY.,  TO  DETERMINE  FUNCTIONALITIES  THAT  CAN  BE  REALIZED  AFLOAT  ON 
PACFLT  SHIPS  TODAY.” 


MSGID 

FROM 

SUBJECT 

021820ZAUG02 

COMCARGRU  7 

EQUIPMENT  -  LACK  OF  A  MULTI-LEVEL  SECURITY 
SYSTEM  AFLOAT 

IDCLS/L/12373-20899/U// 

ORIG/CCG7/LCDR  GREG  HUSMANN 

OBSERVATION: 

OEF  OPERATIONS  WERE  CONDUCTED  AS  PART  OF  AN  INTERNATIONAL  COALITION.  AS  THE 
SENIOR  INTELLIGENCE  ENTITY  AFLOAT,  THE  JCSBATGRU  N2  STAFF  WAS  CHARGED  WITH 
COORDINATING  THE  TIMELY  EXCHANGE  OF  INTELLIGENCE  BETWEEN  MANY  COALITION 
MEMBERS.  SUCH  EXCHANGES  WERE  ACCOMPLISHED  VIA  A  COMPLEX  ARRAY  OF  COMPUTER 
SYSTEMS  OPERATING  AT  SEVEN  DIFFERENT  CLASSIFICATION  LEVELS  (JWICS,  SIPRNET, 
NIPRNET,  STONE  GHOST,  BISON,  COWAN,  AND  LOCE).  WHILE  SUCH  CONFIGURATIONS  ARE 
WORKABLE  OVER  THE  SHORT  TERM,  THEY  PRESENT  MANY  CHALLENGES  THAT  IMPEDE  THE 
TIMELY  FLOW  OF  INTELLIGENCE  WITHIN  A  COALITION  ARCHITECTURE.  THE  REQUIREMENT 
EXISTS  FOR  A  SINGLE  WORK  STATION  EQUIPPED  WITH  COMMON  INTELLIGENCE  APPLICATIONS 
ACROSS  THE  FULL  SPECTRUM  OF  POTENTIAL  SECURITY  CLASSIFICATION  LEVELS. 
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DISCUSSION: 

A  MULTI-LEVEL  SECURITY  SYSTEM  SHOULD  BE  CAPABLE  OF  PROCESSING  AND  EXCHANGING 
DATA  AT  THE  DESIRED  CLASSIFICATION  LEVEL  USING  THE  FOLLOWING  APPLICATIONS:  ALL 
MICROSOFT  OFFICE  APPLICATIONS,  MICROSOFT  CHAT,  WEB  BROWSE,  AND  EMAIL. 
ADDITIONALLY,  THE  SYSTEM  SHOULD  ALSO  HAVE  THE  ABILITY  TO  AUTOMATICALLY 
DISSEMINATE  MARITIME  TRACK  DATA  TO  COALITION  PARTNERS  AT  THE  APPROPRIATE 
CLASSIFICATION  LEVEL.  CURRENTLY  SUCH  FEATURES  ARE  NOT  AVAILABLE  TO  IT-21  OR 
GCCS-M  WORKSTATIONS. 

RECOMMENDATION : 

OVER  THE  LONG  TERM  INCORPORATE  MULTI-  LEVEL  SECURITY  FUNCTIONALITY  INTO  GCCS-M. 
FOR  THE  SHORT  TERM,  RECOMMEND  INSTALLATION/INTEGRATION  OF  WORK  STATIONS  WITH 
THE  MLS  CAPABILITIES  INHERENT  IN  OED  IN  BOTH  CVIC  AND  SUPPLOT  TO  MEET 
REQUIREMENTS  FOR  MLS  AFLOAT. 


MSGID 

FROM 

SUBJECT 

180235Z  DEC  01 

COMSECONDFLT 

SCI  GCCS-M  LAN  UPGRADE  REQUIREMENTS 

“TO  ACHIEVE  NECESSARY  FUNCTIONALITY  COMMENSURATE  WITH  INTELLIGENCE  AND  ISR 
MANAGEMENT  AT  THE  JTF  LEVEL,  A  COMPREHENSIVE  SCI  GCCS-M  LAN  UPGRADE  IS  REQUIRED 
TO  PROVIDE  AN  ACCURATE,  TIMELY  ,  FUSED  ALL-SOURCE,  MULTI- SECURITY  LEVEL 
INTELLIGENCE  PICTURE  TO  SUPPORT  C2F  /  COMSTRIKFLTLANT  MISSIONS.  THE  FOLLOWING 
FUNCTIONALITES  ARE  REQUIRED: 

A.  AUTOMATED  MESSAGE  HANDLING  /  MULTI- SECURITY  LEVEL  INFORMATION  MANAGEMENT 
(1)  SINGLE,  AGGREGATED,  MULTI- SECURITY  LEVEL  DATABASE  SUPPORT,  ACCESS  TO  MULTI¬ 
SECURITY  LEVEL  FILE  SHARING  OF  SCI,  US  ONLY,  NATO  AND  UNCLASSIFIED  RECORD  MESSAGE 
TRAFFIC,  EMAIL  AND  MS  OFFICE  PRODUCTS 

(3)  MULTI-SECURITY  LEVEL  WEB  SERVICES 

B.  ALL-SECURITY-LEVEL  LAND/AIR  /MARITIME  (MERCHANT/SURFACE/  SUBSURFACE)  TRACK 
MANAGER  WITH  HISTORY  AND  TREND  ANALYSIS  CAPABILITY. 

E.  A  SECURITY  LAN  INTERFACE  BETWEEN  U.S.  AND  NATO/COMMMONWEALTH  SYSTEMS,  TO 
INCLUDE:  LINKED  OPS  CENTERS  EUROPE  (LOCE),  COMBINED  OPERATIONAL  INTEL  SYSTEMS 
(COINS),  NATO  INITIAL  DATA  TRANSFER  SYSTEMS  (NIDTS),  MARITIME  COMMAND  CONTROL 
INFORMATION  SYSTEMS  (MCCIS),  JOINT  OPERATION  INTELLIGENCE  INFORMATION  SYSTEM 
(JOIIS),  INITIAL  CAOC  CAPABILITY  (ICC),  AND  INTEL1NK-C/STONEGHOST. 


MSGID 

FROM 

SUBJECT 

211442ZMAY  01 

CINCLANTFLT 

N6A 

CINCLANTFLT  MULTI  SECURITY  LEVEL-MULTI 

LEVEL  SECURITY  (MSL-MLS)  FOCUS  WORKSHOP 
RESULTS 

PARA  2.  BASED  ON  CONFERENCE  RESULTS,  MSL-MLS  SYSTEMS  MUST  PROVIDE: 

A.  REDUCED  HULL,  MECHANICAL  AND  ELECTRICAL  (HM&E)  SHIPBOARD  FOOTPRINT: 


CURRENTLY  THERE  ARE  MULTIPLE  AFLOAT  NETWORKS.  IT  IS  NOT  UNCOMMON  TO  HAVE  A 
SINGLE  AFLOAT  OPERATOR  WHO  MUST  USE  TWO  OR  THREE  COMPUTERS  TO  ACCOMPLISH 
THEIR  MISSION.  THE  MAIN  THREE  OPERATIONAL  NETWORKS  ON  LANTFLT  VESSELS  ARE  SIPR, 
NIPR,  AND  NATO/COALITION.  ON  MANY  PLATFORMS,  THE  HM&E/HE AT ING,  VENTILATION,  AIR 
CONDITIONING  (HVAC)  EQUIPMENT  TO  SUPPORT  TWO  OR  THREE  SEPARATE  NETWORKS  AND 
ASSOCIATED  DESKTOP  COMPUTERS  HAS  OFTEN  EXCEEDED  THE  SHIP'S  ABILITY  TO  SUPPORT 
THEM  WITH  ADEQUATE  POWER  AND  COOLING. 

B.  ABILITY  TO  SECURELY  EXCHANGE  DATA  BETWEEN  USERS/SYSTEMS  THAT  PROCESS  DATA 
ON  DIFFERENT  CLASSIFICATION  LEVELS:  IN  ADDITION,  THE  PATH  MUST  BE  CAPABLE  OF  NOT 
HAVING  DATA  "LEAK"  FROM  HIGH  SIDE  TO  LOW  SIDE. 

C.  ABILITY  FOR  MSL-MLS  TO  OPERATE  IN  BANDWIDTH  CONSTRAINED  ENVIRONMENTS:  THERE 
ARE  TACTICAL  UNITS  WHO  RELY  ON  DATA  PIPES  OF  28KB  OR  LESS  TO  ACCOMPLISH  THEIR 
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MISSION.  MSL-MLS  SOLUTIONS  MUST  BE  DESIGNED  TO  OPERATE  AT  THE  LOWEST  COMMON 
DENOMINATOR.  D.  ABILITY  FOR  MSL-MLS  TO  OPERATE  IN  DEGRADED  ENVIRONMENT: WITH 
INCREASING  RELIANCE  BY  OUR  OPERATING  FORCES  TO  CONDUCT  THEIR  MISSIONS  VIA  SIPR 
AND  NIPR,  MSL-MLS  SOLUTIONS  MUST  BE  BUILT  ROBUST  ENOUGH  TO  "FIGHT  HURT". 

MSGID 

FROM 

SUBJECT 

272118ZFEB01 

COMSECONDFLT 

FLEET  REQUIREMENTS  FOR  MULTI  LEVEL 

NETWORKS 

PARA  4.B.  ACCELERATED  DEVELOPMENT  AND  FIELDING  OF  FULL  CONTENT-BASED  MLS 

SOLUTIONS. 

Table  7.  Reference  Naval  Messages  Defining  CDS  Requirements  (From  Various) 
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INITIAL  DISTRIBUTION  LIST 


1 .  Defense  Technical  Infonnation  Center 
Ft.  Belvoir,  Virginia 

2.  Dudley  Knox  Library 
Naval  Postgraduate  School 
Monterey,  California 

3.  Professor  Wally  Owen 
Naval  Postgraduate  School 
Monterey,  California 

4.  LCDR  Pat  Mack 

SPAWAR  Detachment  Yokosuka 
Y okosuka,  JAPAN 

5.  Christopher  J.  Newcomb 
SPAWAR 

San  Diego,  CA 

6.  John  J.  Falbo,  II 
SPAWARSYSCEN-San  Diego 
San  Diego,  CA 
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